mirror of
https://github.com/garrytan/gstack.git
synced 2026-05-08 21:49:45 +08:00
feat: Confusion Protocol, Hermes + GBrain hosts, brain-first resolver (v0.18.0.0) (#1005)
* feat: add Confusion Protocol to preamble resolver Injects a high-stakes ambiguity gate at preamble tier >= 2 so all workflow skills get it. Fires when Claude encounters architectural decisions, data model changes, destructive operations, or contradictory requirements. Does NOT fire on routine coding. Addresses Karpathy failure mode #1 (wrong assumptions) with an inline STOP gate instead of relying on workflow skill invocation. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat: add Hermes and GBrain host configs Hermes: tool rewrites for terminal/read_file/patch/delegate_task, paths to ~/.hermes/skills/gstack, AGENTS.md config file. GBrain: coding skills become brain-aware when GBrain mod is installed. Same tool rewrites as OpenClaw (agents spawn Claude Code via ACP). GBRAIN_CONTEXT_LOAD and GBRAIN_SAVE_RESULTS NOT suppressed on gbrain host, enabling brain-first lookup and save-to-brain behavior. Both registered in hosts/index.ts with setup script redirect messages. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat: GBrain resolver — brain-first lookup and save-to-brain New scripts/resolvers/gbrain.ts with two resolver functions: - GBRAIN_CONTEXT_LOAD: search brain for context before skill starts - GBRAIN_SAVE_RESULTS: save skill output to brain after completion Placeholders added to 4 thinking skill templates (office-hours, investigate, plan-ceo-review, retro). Resolves to empty string on all hosts except gbrain via suppressedResolvers. GBRAIN suppression added to all 9 non-gbrain host configs. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat: wire slop:diff into /review as advisory diagnostic Adds Step 3.5 to the review template: runs bun run slop:diff against the base branch to catch AI code quality issues (empty catches, redundant return await, overcomplicated abstractions). Advisory only, never blocking. Skips silently if slop-scan is not installed. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * docs: add Karpathy compatibility note to README Positions gstack as the workflow enforcement layer for Karpathy-style CLAUDE.md rules (17K stars). Links to forrestchang/andrej-karpathy-skills. Maps each Karpathy failure mode to the gstack skill that addresses it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: improve native OpenClaw thinking skills office-hours: add design doc path visibility message after writing ceo-review: add HARD GATE reminder at review section transitions retro: add non-git context support (check memory for meeting notes) Mirrors template improvements to hand-crafted native skills. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * chore: update tests and golden fixtures for new hosts - Host count: 8 → 10 (hermes, gbrain) - OpenClaw adapter test: expects undefined (dead code removed) - Golden ship fixtures: updated with Confusion Protocol + vendoring Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * chore: regenerate all SKILL.md files Regenerated from templates after Confusion Protocol, GBrain resolver placeholders, slop:diff in review, HARD GATE reminders, investigation learnings, design doc visibility, and retro non-git context changes. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * docs: update project documentation for v0.18.0.0 - CHANGELOG: add v0.18.0.0 entry (Confusion Protocol, Hermes, GBrain, slop in review, Karpathy note, skill improvements) - CLAUDE.md: add hermes.ts and gbrain.ts to hosts listing - README.md: update agent count 8→10, add Hermes + GBrain to table - VERSION: bump to 0.18.0.0 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * chore: sync package.json version to 0.18.0.0 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: extract Step 0 from review SKILL.md in E2E test The review-base-branch E2E test was copying the full 1493-line review/SKILL.md into the test fixture. The agent spent 8+ turns reading it in chunks, leaving only 7 turns for actual work, causing error_max_turns on every attempt. Now extracts only Step 0 (base branch detection, ~50 lines) which is all the test actually needs. Follows the CLAUDE.md rule: "NEVER copy a full SKILL.md file into an E2E test fixture." Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat: update GBrain and Hermes host configs for v0.10.0 integration GBrain: add 'triggers' to keepFields so generated skills pass checkResolvable() validation. Add version compat comment. Hermes: un-suppress GBRAIN_CONTEXT_LOAD and GBRAIN_SAVE_RESULTS. The resolvers handle GBrain-not-installed gracefully, so Hermes agents with GBrain as a mod get brain features automatically. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat: GBrain resolver DX improvements and preamble health check Resolver changes: - gbrain query → gbrain search (fast keyword search, not expensive hybrid) - Add keyword extraction guidance for agents - Show explicit gbrain put_page syntax with --title, --tags, heredoc - Add entity enrichment with false-positive filter - Name throttle error patterns (exit code 1, stderr keywords) - Add data-research routing for investigate skill - Expand skillSaveMap from 4 to 8 entries - Add brain operation telemetry summary Preamble changes: - Add gbrain doctor --fast --json health check for gbrain/hermes hosts - Parse check failures/warnings count - Show failing check details when score < 50 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: preserve keepFields in allowlist frontmatter mode The allowlist mode hard-coded name + description reconstruction but never iterated keepFields for additional fields. Adding 'triggers' to keepFields was a no-op because the field was silently stripped. Now iterates keepFields and preserves any field beyond name/description from the source template frontmatter, including YAML arrays. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat: add triggers to all 38 skill templates Multi-word, skill-specific trigger keywords for GBrain's RESOLVER.md router. Each skill gets 3-6 triggers derived from its "Use when asked to..." description text. Avoids single generic words that would collide across skills (e.g., "debug this" not "debug"). These are distinct from voice-triggers (speech-to-text aliases) and serve GBrain's checkResolvable() validation. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * chore: regenerate all SKILL.md files and update golden fixtures Regenerated from updated templates (triggers, brain placeholders, resolver DX improvements, preamble health check). Golden fixtures updated to match. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: settings-hook remove exits 1 when nothing to remove gstack-settings-hook remove was exiting 0 when settings.json didn't exist, causing gstack-uninstall to report "SessionStart hook" as removed on clean systems where nothing was installed. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * docs: update project documentation for GBrain v0.10.0 integration ARCHITECTURE.md: added GBRAIN_CONTEXT_LOAD and GBRAIN_SAVE_RESULTS to resolver table. CHANGELOG.md: expanded v0.18.0.0 entry with GBrain v0.10.0 integration details (triggers, expanded brain-awareness, DX improvements, Hermes brain support), updated date. CLAUDE.md: added gbrain to resolvers/ directory comment. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: routing E2E stops writing to user's ~/.claude/skills/ installSkills() was copying SKILL.md files to both project-level (.claude/skills/ in tmpDir) and user-level (~/.claude/skills/). Writing to the user's real install fails when symlinks point to different worktrees or dangling targets (ENOENT on copyFileSync). Now installs to project-level only. The test already sets cwd to the tmpDir, so project-level discovery works. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * chore: scale Gemini E2E back to smoke test Gemini CLI gets lost in worktrees on complex tasks (review times out at 600s, discover-skill hits exit 124). Nobody uses Gemini for gstack skill execution. Replace the two failing tests (gemini-discover-skill and gemini-review-findings) with a single smoke test that verifies Gemini can start and read the README. 90s timeout, no skill invocation. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -19,6 +19,11 @@ allowed-tools:
|
||||
- Bash
|
||||
- AskUserQuestion
|
||||
- WebSearch
|
||||
triggers:
|
||||
- think bigger
|
||||
- expand scope
|
||||
- strategy review
|
||||
- rethink this plan
|
||||
---
|
||||
<!-- AUTO-GENERATED from SKILL.md.tmpl — do not edit directly -->
|
||||
<!-- Regenerate: bun run gen:skill-docs -->
|
||||
@@ -262,6 +267,8 @@ AI orchestrator (e.g., OpenClaw). In spawned sessions:
|
||||
- Focus on completing the task and reporting results via prose output.
|
||||
- End with a completion report: what shipped, decisions made, anything uncertain.
|
||||
|
||||
|
||||
|
||||
## Voice
|
||||
|
||||
You are GStack, an open source AI builder framework shaped by Garry Tan's product, startup, and engineering judgment. Encode how he thinks, not his biography.
|
||||
@@ -380,6 +387,19 @@ AI makes completeness near-free. Always recommend the complete option over short
|
||||
|
||||
Include `Completeness: X/10` for each option (10=all edge cases, 7=happy path, 3=shortcut).
|
||||
|
||||
## Confusion Protocol
|
||||
|
||||
When you encounter high-stakes ambiguity during coding:
|
||||
- Two plausible architectures or data models for the same requirement
|
||||
- A request that contradicts existing patterns and you're unsure which to follow
|
||||
- A destructive operation where the scope is unclear
|
||||
- Missing context that would change your approach significantly
|
||||
|
||||
STOP. Name the ambiguity in one sentence. Present 2-3 options with tradeoffs.
|
||||
Ask the user. Do not guess on architectural or data model decisions.
|
||||
|
||||
This does NOT apply to routine coding, small features, or obvious changes.
|
||||
|
||||
## Repo Ownership — See Something, Say Something
|
||||
|
||||
`REPO_MODE` controls how to handle issues outside your branch:
|
||||
@@ -868,6 +888,8 @@ matches a past learning, display:
|
||||
This makes the compounding visible. The user should see that gstack is getting
|
||||
smarter on their codebase over time.
|
||||
|
||||
|
||||
|
||||
## Step 0: Nuclear Scope Challenge + Mode Selection
|
||||
|
||||
### 0A. Premise Challenge
|
||||
@@ -1090,6 +1112,7 @@ After mode is selected, confirm which implementation approach (from 0C-bis) appl
|
||||
|
||||
Once selected, commit fully. Do not silently drift.
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
## Review Sections (11 sections, after scope and mode are agreed)
|
||||
|
||||
@@ -1119,6 +1142,7 @@ Evaluate and diagram:
|
||||
|
||||
Required ASCII diagram: full system architecture showing new components and their relationships to existing ones.
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 2: Error & Rescue Map
|
||||
This is the section that catches silent failures. It is not optional.
|
||||
@@ -1148,6 +1172,7 @@ Rules for this section:
|
||||
* For each GAP (unrescued error that should be rescued): specify the rescue action and what the user should see.
|
||||
* For LLM/AI service calls specifically: what happens when the response is malformed? When it's empty? When it hallucinates invalid JSON? When the model returns a refusal? Each of these is a distinct failure mode.
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 3: Security & Threat Model
|
||||
Security is not a sub-bullet of architecture. It gets its own section.
|
||||
@@ -1163,6 +1188,7 @@ Evaluate:
|
||||
|
||||
For each finding: threat, likelihood (High/Med/Low), impact (High/Med/Low), and whether the plan mitigates it.
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 4: Data Flow & Interaction Edge Cases
|
||||
This section traces data through the system and interactions through the UI with adversarial thoroughness.
|
||||
@@ -1199,6 +1225,7 @@ For each node: what happens on each shadow path? Is it tested?
|
||||
```
|
||||
Flag any unhandled edge case as a gap. For each gap, specify the fix.
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 5: Code Quality Review
|
||||
Evaluate:
|
||||
@@ -1211,6 +1238,7 @@ Evaluate:
|
||||
* Under-engineering check. Anything fragile, assuming happy path only, or missing obvious defensive checks?
|
||||
* Cyclomatic complexity. Flag any new method that branches more than 5 times. Propose a refactor.
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 6: Test Review
|
||||
Make a complete diagram of every new thing this plan introduces:
|
||||
@@ -1251,6 +1279,7 @@ Load/stress test requirements: For any new codepath called frequently or process
|
||||
|
||||
For LLM/prompt changes: Check CLAUDE.md for the "Prompt/LLM changes" file patterns. If this plan touches ANY of those patterns, state which eval suites must be run, which cases should be added, and what baselines to compare against.
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 7: Performance Review
|
||||
Evaluate:
|
||||
@@ -1262,6 +1291,7 @@ Evaluate:
|
||||
* Slow paths. Top 3 slowest new codepaths and estimated p99 latency.
|
||||
* Connection pool pressure. New DB connections, Redis connections, HTTP connections?
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 8: Observability & Debuggability Review
|
||||
New systems break. This section ensures you can see why.
|
||||
@@ -1278,6 +1308,7 @@ Evaluate:
|
||||
**EXPANSION and SELECTIVE EXPANSION addition:**
|
||||
* What observability would make this feature a joy to operate? (For SELECTIVE EXPANSION, include observability for any accepted cherry-picks.)
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 9: Deployment & Rollout Review
|
||||
Evaluate:
|
||||
@@ -1293,6 +1324,7 @@ Evaluate:
|
||||
**EXPANSION and SELECTIVE EXPANSION addition:**
|
||||
* What deploy infrastructure would make shipping this feature routine? (For SELECTIVE EXPANSION, assess whether accepted cherry-picks change the deployment risk profile.)
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 10: Long-Term Trajectory Review
|
||||
Evaluate:
|
||||
@@ -1308,6 +1340,7 @@ Evaluate:
|
||||
* Platform potential. Does this create capabilities other features can leverage?
|
||||
* (SELECTIVE EXPANSION only) Retrospective: Were the right cherry-picks accepted? Did any rejected expansions turn out to be load-bearing for the accepted ones?
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 11: Design & UX Review (skip if no UI scope detected)
|
||||
The CEO calling in the designer. Not a pixel-level audit — that's /plan-design-review and /design-review. This is ensuring the plan has design intentionality.
|
||||
@@ -1330,6 +1363,7 @@ Required ASCII diagram: user flow showing screens/states and transitions.
|
||||
|
||||
If this plan has significant UI scope, recommend: "Consider running /plan-design-review for a deep design review of this plan before implementation."
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
## Outside Voice — Independent Plan Challenge (optional, recommended)
|
||||
|
||||
@@ -1797,6 +1831,8 @@ staleness detection: if those files are later deleted, the learning can be flagg
|
||||
**Only log genuine discoveries.** Don't log obvious things. Don't log things the user
|
||||
already knows. A good test: would this insight save time in a future session? If yes, log it.
|
||||
|
||||
|
||||
|
||||
## Mode Quick Reference
|
||||
```
|
||||
┌────────────────────────────────────────────────────────────────────────────────┐
|
||||
|
||||
@@ -19,6 +19,11 @@ allowed-tools:
|
||||
- Bash
|
||||
- AskUserQuestion
|
||||
- WebSearch
|
||||
triggers:
|
||||
- think bigger
|
||||
- expand scope
|
||||
- strategy review
|
||||
- rethink this plan
|
||||
---
|
||||
|
||||
{{PREAMBLE}}
|
||||
@@ -190,6 +195,8 @@ Feed into the Premise Challenge (0A) and Dream State Mapping (0C). If you find a
|
||||
|
||||
{{LEARNINGS_SEARCH}}
|
||||
|
||||
{{GBRAIN_CONTEXT_LOAD}}
|
||||
|
||||
## Step 0: Nuclear Scope Challenge + Mode Selection
|
||||
|
||||
### 0A. Premise Challenge
|
||||
@@ -352,6 +359,7 @@ After mode is selected, confirm which implementation approach (from 0C-bis) appl
|
||||
|
||||
Once selected, commit fully. Do not silently drift.
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
## Review Sections (11 sections, after scope and mode are agreed)
|
||||
|
||||
@@ -381,6 +389,7 @@ Evaluate and diagram:
|
||||
|
||||
Required ASCII diagram: full system architecture showing new components and their relationships to existing ones.
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 2: Error & Rescue Map
|
||||
This is the section that catches silent failures. It is not optional.
|
||||
@@ -410,6 +419,7 @@ Rules for this section:
|
||||
* For each GAP (unrescued error that should be rescued): specify the rescue action and what the user should see.
|
||||
* For LLM/AI service calls specifically: what happens when the response is malformed? When it's empty? When it hallucinates invalid JSON? When the model returns a refusal? Each of these is a distinct failure mode.
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 3: Security & Threat Model
|
||||
Security is not a sub-bullet of architecture. It gets its own section.
|
||||
@@ -425,6 +435,7 @@ Evaluate:
|
||||
|
||||
For each finding: threat, likelihood (High/Med/Low), impact (High/Med/Low), and whether the plan mitigates it.
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 4: Data Flow & Interaction Edge Cases
|
||||
This section traces data through the system and interactions through the UI with adversarial thoroughness.
|
||||
@@ -461,6 +472,7 @@ For each node: what happens on each shadow path? Is it tested?
|
||||
```
|
||||
Flag any unhandled edge case as a gap. For each gap, specify the fix.
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 5: Code Quality Review
|
||||
Evaluate:
|
||||
@@ -473,6 +485,7 @@ Evaluate:
|
||||
* Under-engineering check. Anything fragile, assuming happy path only, or missing obvious defensive checks?
|
||||
* Cyclomatic complexity. Flag any new method that branches more than 5 times. Propose a refactor.
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 6: Test Review
|
||||
Make a complete diagram of every new thing this plan introduces:
|
||||
@@ -513,6 +526,7 @@ Load/stress test requirements: For any new codepath called frequently or process
|
||||
|
||||
For LLM/prompt changes: Check CLAUDE.md for the "Prompt/LLM changes" file patterns. If this plan touches ANY of those patterns, state which eval suites must be run, which cases should be added, and what baselines to compare against.
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 7: Performance Review
|
||||
Evaluate:
|
||||
@@ -524,6 +538,7 @@ Evaluate:
|
||||
* Slow paths. Top 3 slowest new codepaths and estimated p99 latency.
|
||||
* Connection pool pressure. New DB connections, Redis connections, HTTP connections?
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 8: Observability & Debuggability Review
|
||||
New systems break. This section ensures you can see why.
|
||||
@@ -540,6 +555,7 @@ Evaluate:
|
||||
**EXPANSION and SELECTIVE EXPANSION addition:**
|
||||
* What observability would make this feature a joy to operate? (For SELECTIVE EXPANSION, include observability for any accepted cherry-picks.)
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 9: Deployment & Rollout Review
|
||||
Evaluate:
|
||||
@@ -555,6 +571,7 @@ Evaluate:
|
||||
**EXPANSION and SELECTIVE EXPANSION addition:**
|
||||
* What deploy infrastructure would make shipping this feature routine? (For SELECTIVE EXPANSION, assess whether accepted cherry-picks change the deployment risk profile.)
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 10: Long-Term Trajectory Review
|
||||
Evaluate:
|
||||
@@ -570,6 +587,7 @@ Evaluate:
|
||||
* Platform potential. Does this create capabilities other features can leverage?
|
||||
* (SELECTIVE EXPANSION only) Retrospective: Were the right cherry-picks accepted? Did any rejected expansions turn out to be load-bearing for the accepted ones?
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
### Section 11: Design & UX Review (skip if no UI scope detected)
|
||||
The CEO calling in the designer. Not a pixel-level audit — that's /plan-design-review and /design-review. This is ensuring the plan has design intentionality.
|
||||
@@ -592,6 +610,7 @@ Required ASCII diagram: user flow showing screens/states and transitions.
|
||||
|
||||
If this plan has significant UI scope, recommend: "Consider running /plan-design-review for a deep design review of this plan before implementation."
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
**Reminder: Do NOT make any code changes. Review only.**
|
||||
|
||||
{{CODEX_PLAN_REVIEW}}
|
||||
|
||||
@@ -783,6 +802,8 @@ If promoted, copy the CEO plan content to `docs/designs/{FEATURE}.md` (create th
|
||||
|
||||
{{LEARNINGS_LOG}}
|
||||
|
||||
{{GBRAIN_SAVE_RESULTS}}
|
||||
|
||||
## Mode Quick Reference
|
||||
```
|
||||
┌────────────────────────────────────────────────────────────────────────────────┐
|
||||
|
||||
Reference in New Issue
Block a user