mirror of
https://github.com/garrytan/gstack.git
synced 2026-09-22 12:50:50 +02:00
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -750,3 +750,13 @@ Write questions, progress updates, reports, and artifacts in the language used b
|
||||
|
||||
Persist a learning only when the interaction contains a useful, reusable signal such as an explicit preference, correction, accepted recommendation, or rejected direction. Track helpful and harmful outcomes separately. Do not manufacture a learning merely because a workflow completed.
|
||||
<!-- GSTACK2_BUG_FIX_END pr=2030 -->
|
||||
|
||||
<!-- GSTACK2_BUG_FIX_START pr=1049 anchor=GSTACK2_FIX_1049_NO_DOC_OUTCOME -->
|
||||
## Upstream judgment port: PR #1049
|
||||
|
||||
[Refuse to log success without a persisted design doc](https://github.com/garrytan/gstack/pull/1049)
|
||||
|
||||
### Artifact-verified outcome
|
||||
|
||||
The design doc file is the artifact of this session. Before the telemetry block runs, verify that a design doc actually persisted to disk. When no doc was written, the outcome must be `no_doc`, never `success`, no matter how productive the conversation felt. A session without a persisted artifact is not a successful session, and downstream analytics depend on that distinction to catch skipped review phases.
|
||||
<!-- GSTACK2_BUG_FIX_END pr=1049 -->
|
||||
|
||||
@@ -285,3 +285,13 @@ Default to a normalized relational model. Denormalization needs a measured perfo
|
||||
|
||||
Persist a learning only when the interaction contains a useful, reusable signal such as an explicit preference, correction, accepted recommendation, or rejected direction. Track helpful and harmful outcomes separately. Do not manufacture a learning merely because a workflow completed.
|
||||
<!-- GSTACK2_BUG_FIX_END pr=2030 -->
|
||||
|
||||
<!-- GSTACK2_BUG_FIX_START pr=592 anchor=GSTACK2_FIX_592_PRE_MORTEM -->
|
||||
## Upstream judgment port: PR #592
|
||||
|
||||
[Run a pre-mortem before challenging scope](https://github.com/garrytan/gstack/pull/592)
|
||||
|
||||
### Pre-mortem before scope challenge
|
||||
|
||||
Before reviewing anything, run a pre-mortem: it is three months later and this plan failed, name the top three reasons why. Reason from production reality, not the plan's internal logic, and name concrete failure modes (data loss, performance cliff, security hole, team confusion), not abstract worries. Present those three failure modes to the user before the scope challenge, which follows the pre-mortem rather than opening the review.
|
||||
<!-- GSTACK2_BUG_FIX_END pr=592 -->
|
||||
|
||||
Reference in New Issue
Block a user