feat(gstack2): port 6 judgment overlays (#1102 #1049 #592 #696 #1523 #1053)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude
2026-07-21 19:19:23 -07:00
parent 268e9ed10b
commit d72133e18e
30 changed files with 503 additions and 40 deletions
@@ -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 -->