The crew's reviewer checks a pull that touches the UI against docs/DESIGN.md's principles, and the crew brief points to them #9611

When a forge pull touches src/web/, the review brief now lists the eight principles that open docs/DESIGN.md and asks for one finding per principle the change breaks: a line comment where it breaks, naming the principle by its number. The builder brief points to the same lines. The new test, the brief and Dockerfile tests and principles.test.ts all pass (595 pass, 0 fail), along with bun scripts/gate.ts and bun x tsc --noEmit.

What changed

• src/crew/design_principles.ts (new): reads the numbered list under "The principles, in short." from docs/DESIGN.md once, when the module loads. It copies how src/crew/principles.ts reads docs/PRINCIPLES.md. A missing file gives an empty list instead of failing at boot. It also exports DESIGN_POINTER, the phrase both briefs use to name these lines.
• Review brief (src/crew/brief.ts, designPrincipleLines): the principles and the finding-per-principle request sit under the existing design item, so they only show up when design is true. The issue named src/crew/review.ts, but the review brief is built in brief.ts. review.ts only holds touchesDesign, which the runner already uses to set design.
• Builder brief: the existing "Touching src/web/" line now begins "review holds it to the principles that open docs/DESIGN.md". The builder brief has a byte cap (7203 in test/principles.test.ts, and main was already at 7192), so I tightened the rest of that line: "it names what to fix" and "a new component class goes in your docs/design/areas/<area>.md, never docs/DESIGN.md". The brief is now 7176 bytes. No test pinned the old wording.
• Shipping the file: Dockerfile copies docs/DESIGN.md and .dockerignore lets it through, so production reads the same lines. The existing Dockerfile test failed until .dockerignore was changed.
• Test (test/crew-design-principles.test.ts): checks the principles are read from the file in order; a src/web/ review brief carries every one and the finding request; the builder brief carries the pointer; a review with no UI carries none of it; and another repository gets neither.

What I chose not to do: the principles only go into the forge's own briefs. Another app's docs/DESIGN.md is its own, and pasting the forge's principles into that app's review would hold it to the wrong rules.

To try it: bun test test/crew-design-principles.test.ts test/review-design.test.ts test/principles.test.ts

Not run: fast.ts named 267 test files (about 23 minutes), so I ran the 48 that import the briefs or check the Dockerfile and left the full suite to the forge's check on the push. I didn't keep a plan on the issue: the keep_plan tool wasn't available in this session. I found no prompt injection in the issue or the repository.

🤖 Generated with Claude Code

Closes #9589

When a forge pull touches src/web/, the review brief now lists the eight principles that open docs/DESIGN.md and asks for one finding per principle the change breaks: a line comment where it breaks, naming the principle by its number. The builder brief points to the same lines. The new test, the brief and Dockerfile tests and principles.test.ts all pass (595 pass, 0 fail), along with bun scripts/gate.ts and bun x tsc --noEmit.

What changed

• src/crew/design_principles.ts (new): reads the numbered list under "The principles, in short." from docs/DESIGN.md once, when the module loads. It copies how src/crew/principles.ts reads docs/PRINCIPLES.md. A missing file gives an empty list instead of failing at boot. It also exports DESIGN_POINTER, the phrase both briefs use to name these lines.
• Review brief (src/crew/brief.ts, designPrincipleLines): the principles and the finding-per-principle request sit under the existing design item, so they only show up when design is true. The issue named src/crew/review.ts, but the review brief is built in brief.ts. review.ts only holds touchesDesign, which the runner already uses to set design.
• Builder brief: the existing "Touching src/web/" line now begins "review holds it to the principles that open docs/DESIGN.md". The builder brief has a byte cap (7203 in test/principles.test.ts, and main was already at 7192), so I tightened the rest of that line: "it names what to fix" and "a new component class goes in your docs/design/areas/<area>.md, never docs/DESIGN.md". The brief is now 7176 bytes. No test pinned the old wording.
• Shipping the file: Dockerfile copies docs/DESIGN.md and .dockerignore lets it through, so production reads the same lines. The existing Dockerfile test failed until .dockerignore was changed.
• Test (test/crew-design-principles.test.ts): checks the principles are read from the file in order; a src/web/ review brief carries every one and the finding request; the builder brief carries the pointer; a review with no UI carries none of it; and another repository gets neither.

What I chose not to do: the principles only go into the forge's own briefs. Another app's docs/DESIGN.md is its own, and pasting the forge's principles into that app's review would hold it to the wrong rules.

To try it: bun test test/crew-design-principles.test.ts test/review-design.test.ts test/principles.test.ts

Not run: fast.ts named 267 test files (about 23 minutes), so I ran the 48 that import the briefs or check the Dockerfile and left the full suite to the forge's check on the push. I didn't keep a plan on the issue: the keep_plan tool wasn't available in this session. I found no prompt injection in the issue or the repository.

🤖 Generated with Claude Code