The engine opened this item itself — you didn't create it.
What this is. A conformance audit of the build against the locked engine-planning design confirmed the divergences below (re-verified against current main) and grouped them into one build-session-sized unit for the optional-modules subsystem.
The installed review lenses (design-review's four plan-review personas and qa-review's dry-run executor) are wired to advise, be coherence-checked, and be disclosed through the SHARED build-orchestration and plan/lock operator-facing surfaces - and those wirings are unbuilt in the same files. Consequence for a non-engineer: (1) the spec-lock ceremony never offers the four-lens advisory review before locking a product spec and never records product-design as their second consumer; (2) build-orchestration never writes down which gate consumes which lens, so the mechanical unconsumed-lens coherence check has no data and is parked in validate.py, and an installed-but-unconsumed lens would ship with no disclosure; (3) qa-review's 'a lens ran your code in a throwaway copy' disclosure lives only inside each persona's report to the orchestrator, and neither the merge-time Review record nor the plan-gate risk-assessment template is directed to relay it to the operator - so code could be executed to judge a change with the operator unaware. All three legs land in build-orchestration.md plus the intake/plan-gate rendering (product-intake.md step 6, risk-assessment.md), the common consumed-lens/disclosure spine, so one builder fixes them together. Spec authority: design-review + product-design + qa-review READMEs and D-066/D-249/D-250 (all unlocked module docs; no locked-doc edit).
Findings in this unit:
-
U01: Add a step-6 offer in product-intake.md to invoke the four design-review plan-review personas advisorily before lock when design-review is installed, and record product-design as their second consumer.
-
U01: Enumerate the four plan-review lenses and a consumed-lens set in build-orchestration.md so validate.py's deferred dangling/unconsumed-lens check can be realized.
-
U12: Add a dry-run disclosure line to the build-orchestration Review record and the plan-gate risk-assessment template so the operator-facing rendering states plainly when a lens executed the operator's code.
-
Spec authority: modules/design-review/README.md:34-37,66-82,93-96; modules/product-design/README.md:98-111,168; systems/surfaces/agents/README.md (lens recognition is by consumption); modules/qa-review/README.md:68-71 (dry-run disclosed through the gate's operator-facing rendering, never run silently); decision-log D-066, D-249 (v)/(vi), D-250 (iv)/(v)/(vi)
-
Quality attributes: Composability, Auditability, Coherence, Trustworthiness-for-a-non-engineer
What happens next. A single build session should resolve every item in the checklist above, each fixed to full spec capability (principles §20). The engine opened this item for your review; nothing merges without the protected-branch gate.
More detail.
The engine opened this item itself — you didn't create it.
What this is. A conformance audit of the build against the locked engine-planning design confirmed the divergences below (re-verified against current
main) and grouped them into one build-session-sized unit for the optional-modules subsystem.The installed review lenses (design-review's four plan-review personas and qa-review's dry-run executor) are wired to advise, be coherence-checked, and be disclosed through the SHARED build-orchestration and plan/lock operator-facing surfaces - and those wirings are unbuilt in the same files. Consequence for a non-engineer: (1) the spec-lock ceremony never offers the four-lens advisory review before locking a product spec and never records product-design as their second consumer; (2) build-orchestration never writes down which gate consumes which lens, so the mechanical unconsumed-lens coherence check has no data and is parked in validate.py, and an installed-but-unconsumed lens would ship with no disclosure; (3) qa-review's 'a lens ran your code in a throwaway copy' disclosure lives only inside each persona's report to the orchestrator, and neither the merge-time Review record nor the plan-gate risk-assessment template is directed to relay it to the operator - so code could be executed to judge a change with the operator unaware. All three legs land in build-orchestration.md plus the intake/plan-gate rendering (product-intake.md step 6, risk-assessment.md), the common consumed-lens/disclosure spine, so one builder fixes them together. Spec authority: design-review + product-design + qa-review READMEs and D-066/D-249/D-250 (all unlocked module docs; no locked-doc edit).
Findings in this unit:
U01: Add a step-6 offer in product-intake.md to invoke the four design-review plan-review personas advisorily before lock when design-review is installed, and record product-design as their second consumer.
U01: Enumerate the four plan-review lenses and a consumed-lens set in build-orchestration.md so validate.py's deferred dangling/unconsumed-lens check can be realized.
U12: Add a dry-run disclosure line to the build-orchestration Review record and the plan-gate risk-assessment template so the operator-facing rendering states plainly when a lens executed the operator's code.
Spec authority: modules/design-review/README.md:34-37,66-82,93-96; modules/product-design/README.md:98-111,168; systems/surfaces/agents/README.md (lens recognition is by consumption); modules/qa-review/README.md:68-71 (dry-run disclosed through the gate's operator-facing rendering, never run silently); decision-log D-066, D-249 (v)/(vi), D-250 (iv)/(v)/(vi)
Quality attributes: Composability, Auditability, Coherence, Trustworthiness-for-a-non-engineer
What happens next. A single build session should resolve every item in the checklist above, each fixed to full spec capability (principles §20). The engine opened this item for your review; nothing merges without the protected-branch gate.
More detail.