Improve autonomous implementation review convergence

.agents/skills/recipe-build/SKILL.md

@@ -59,7 +59,9 @@ Apply subagents-orchestration-guide `Requirement Change Detection During Flow` a
 
 ## 8. Final Verification
 
-Apply `subagents-orchestration-guide` Post-Implementation Verification to the actual files changed by completed tasks and their governing documents. Route required fixes through the same task cycle and apply its Post-Verification Rerun Rule.
+Apply `subagents-orchestration-guide` Post-Implementation Review to the actual files changed by completed tasks and their governing documents. Route required fixes through the same task cycle.
+
+Apply a security-reviewer finding only when leaving it unresolved would violate an explicit governing requirement or repository rule, or leave a concrete material security failure in the actual reachable trust model. The violated requirement, rule, or failure defines implementation scope: route the smallest correction that resolves it, treating the reviewer's suggestion as one candidate implementation.
 
 ## 9. Cleanup and Report
 

.agents/skills/recipe-front-build/SKILL.md

@@ -51,7 +51,9 @@ Apply subagents-orchestration-guide `Requirement Change Detection During Flow` a
 
 ## 7. Final Verification
 
-Apply `subagents-orchestration-guide` Post-Implementation Verification to the actual files changed by completed tasks and their governing documents. Route required fixes through the frontend task cycle and apply its Post-Verification Rerun Rule.
+Apply `subagents-orchestration-guide` Post-Implementation Review to the actual files changed by completed tasks and their governing documents. Route required fixes through the frontend task cycle.
+
+Apply a security-reviewer finding only when leaving it unresolved would violate an explicit governing requirement or repository rule, or leave a concrete material security failure in the actual reachable trust model. The violated requirement, rule, or failure defines implementation scope: route the smallest correction that resolves it, treating the reviewer's suggestion as one candidate implementation.
 
 ## 8. Cleanup and Report
 

.agents/skills/recipe-front-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: recipe-front-review
-description: "Frontend Design Doc compliance and security validation with optional auto-fixes using React-specific quality checks."
+description: "Reviews completed frontend implementation for governing-source compliance, scope economy, repository quality, and security, and applies user-approved React corrections."
 ---
 
 **Context**: Post-implementation quality assurance for React/TypeScript frontend
@@ -17,7 +17,7 @@ description: "Frontend Design Doc compliance and security validation with option
 
 ## Execution Method
 
-- Compliance validation -> performed by code-reviewer
+- Implementation review -> performed by code-reviewer
 - Security validation -> performed by security-reviewer
 - Code-side fix path -> performed by task-executor-frontend
 - Design-side update path -> performed by technical-designer-frontend in update mode, then document-reviewer, then design-sync when multiple Design Docs exist
@@ -38,7 +38,7 @@ If a single active work plan is explicitly provided or unambiguously resolved fo
 **CANNOT proceed without both a Design Doc and implementation files.**
 
 ### 2. Execute code-reviewer
-Spawn code-reviewer agent: "Validate Design Doc compliance for [design-doc-path]. Work Plan: [resolved work plan path or none]. Review Scope: [literal Review Scope value or none]. Implementation files: [$STEP_1_FILES]. Review mode: full. Return structured JSON report per your Output Format specification."
+Spawn code-reviewer agent: "Review the completed frontend implementation. governingDocuments: [{type: design-doc, path: [design-doc-path]}]. Work Plan: [resolved work plan path or none]. Review Scope: [literal Review Scope value or none]. implementationFiles: [$STEP_1_FILES]. Return the initial review JSON."
 
 **Store output as**: `$STEP_2_OUTPUT`
 
@@ -51,20 +51,21 @@ Spawn security-reviewer with `governingDocuments: [{type: "design-doc", path: [p
 
 If either reviewer returns a blocked or otherwise unusable result, apply Orchestrator Escalation Resolution before continuing.
 
+Apply a security-reviewer finding only when leaving it unresolved would violate an explicit governing requirement or repository rule, or leave a concrete material security failure in the actual reachable trust model. The violated requirement, rule, or failure defines implementation scope: route the smallest correction that resolves it, treating the reviewer's suggestion as one candidate implementation.
+
 **Code compliance criteria (considering project stage)**:
 - `code-reviewer` verdict is `pass`
 
 **Security criteria**:
 - `approved` -> Pass
-- `needs_revision` -> Fail
+- `needs_revision` -> Requires disposition
 
-Report both results from their evidence, then apply Review Resolution before proposing corrections:
+Report required corrections from both results, then apply Review Resolution before proposing corrections:
 
 ```
-Code Compliance: [verdict]
+Implementation Review: [verdict]
   Acceptance Criteria: [fulfilled/unfulfilled items with evidence]
-  Findings: [blocking findings with basis and effect]
-  Recommendations: [non-blocking items]
+  Findings: [required-correction findings with basis and effect]
 
 Security Review: [status from security-reviewer]
   Findings by category:
@@ -74,15 +75,13 @@ Security Review: [status from security-reviewer]
 Proposed corrections:
   c) Code-side fix
   d) Design-side update
-Declined recommendations:
-  - [finding and evidence-backed reason]
 ```
 
 Apply Review Resolution before presenting results. Recommend a correction route only for findings classified `apply` or `user_decision_required`:
 - Use `d` when implementation intent matches the requirement but the Design Doc is stale or too narrow.
-- Use `c` when code drifted from a still-correct Design Doc, or when the finding is reliability, security, or maintainability related.
+- Use `c` when the required correction changes implementation.
 
-Present the review and internally declined recommendations. When no correction remains, proceed to Final Report. Because this recipe is a review request rather than prior implementation authority, ask once before applying the proposed code or document corrections.
+Present the review. When no correction remains, proceed to Final Report. Because this recipe is a review request rather than prior implementation authority, ask once before applying the proposed code or document corrections.
 
 If the user declines corrections, skip fix steps and proceed to Final Report.
 
@@ -92,17 +91,19 @@ If the user declines corrections, skip fix steps and proceed to Final Report.
 2. **Plan fixes**: Use the active execution plan when one exists. When none exists, create one for the accepted fix flow. Create `docs/plans/tasks/review-fixes-YYYYMMDD.md` with only accepted code compliance issues and security required fixes routed to `c`.
 3. **Execute fixes**: Start the Per-Task Change Set, invoke task-executor-frontend with the task file, inspect its result and repository diff, and accumulate its paths.
 4. **Quality check**: Invoke quality-fixer-frontend with `task_file`, `filesModified: taskWriteSet`, and executor operation-verification evidence. On approval, add its paths and commit the reconciled set; repair stubs through task-executor-frontend, accumulate their paths, and resolve blocked results through Orchestrator Escalation Resolution.
-5. **Re-validate**: Run code-reviewer and security-reviewer against the updated Design Doc and actual implementation and fix files. Pass both `prior_feedback: [applied corrections and declined finding IDs with reasons and evidence]` and review the current result normally.
+5. **Re-validate**: Run code-reviewer and security-reviewer against the updated Design Doc and actual implementation and fix files. For code-reviewer, pass `prior_feedback: [the complete initial result, applied corrections, declined finding IDs with reasons and evidence, and the correction paths or diff]` and apply its Rerun Boundary. Pass the applicable corrections and dispositions to security-reviewer.
+
+After any code fix, both review agents must re-run.
 
-After any code fix, both review agents must re-run. Delete the task file only after both pass.
+Apply Review Resolution to rerun findings. Its convergence rule governs any further correction and rerun; code-reviewer receives the latest complete result and the next correction paths or diff.
 
 ENFORCEMENT: Auto-fixes MUST go through quality-fixer-frontend before re-validation. Skipping quality checks invalidates fixes.
 
 ### Final Report
 Delete the review-fix task file this recipe created, if present. Its work is committed; `docs/plans/` is ephemeral working state.
 
 ```
-Code Compliance:
+Implementation Review:
   Initial: [verdict]
   Final: [verdict] (if fixes executed)
 
@@ -114,18 +115,6 @@ Remaining issues:
 - [items requiring manual intervention]
 ```
 
-## Auto-fixable Items
-- Simple unimplemented acceptance criteria
-- Error handling additions
-- Contract definition fixes
-- Function splitting (length/complexity improvements)
-- Security confirmed_risk and defense_gap fixes (input validation, auth checks, output encoding)
-
-## Non-fixable Items
-- Fundamental business logic changes
-- Architecture-level modifications
-- Design Doc deficiencies
-- Committed secrets (blocked -> human intervention)
 
 ## Completion Criteria
 

.agents/skills/recipe-front-review/agents/openai.yaml

@@ -1,7 +1,7 @@
 interface:
   display_name: "recipe-front-review"
-  short_description: "Frontend Design Doc compliance and security validation with React-specific checks"
-  default_prompt: "Use $recipe-front-review to validate frontend: "
+  short_description: "Review frontend scope, quality, and security"
+  default_prompt: "Use $recipe-front-review to review frontend: "
 
 policy:
   allow_implicit_invocation: false

.agents/skills/recipe-fullstack-build/SKILL.md

@@ -69,7 +69,9 @@ Apply subagents-orchestration-guide `Requirement Change Detection During Flow` a
 
 ## 9. Final Verification
 
-Apply `subagents-orchestration-guide` Post-Implementation Verification to the actual files changed by completed tasks and their governing documents. Route required fixes through the layer-selected task cycle and apply its Post-Verification Rerun Rule.
+Apply `subagents-orchestration-guide` Post-Implementation Review to the actual files changed by completed tasks and their governing documents. Route required fixes through the layer-selected task cycle.
+
+Apply a security-reviewer finding only when leaving it unresolved would violate an explicit governing requirement or repository rule, or leave a concrete material security failure in the actual reachable trust model. The violated requirement, rule, or failure defines implementation scope: route the smallest correction that resolves it, treating the reviewer's suggestion as one candidate implementation.
 
 ## 10. Cleanup and Report
 

.agents/skills/recipe-fullstack-implement/SKILL.md

@@ -26,7 +26,9 @@ Resolve the entry from supplied artifacts and repository state. Ask only when di
 
 Apply the Fullstack Flow exposed by `subagents-orchestration-guide` with backend, frontend, and shared routing. The orchestrator directly owns artifact/path resolution, execution-plan updates, approval recording, task-set computation, commits, and lightweight checks; invoke the named specialists for analysis, authoring, implementation, review, and quality judgment.
 
-Reuse the active execution plan or register the material remaining phases once. Follow the Fullstack Flow's document approvals. After implementation-scope approval, execute tasks autonomously through its filename routing, Per-Task Change Set, quality gate, commit, and Post-Implementation Verification.
+Reuse the active execution plan or register the material remaining phases once. Follow the Fullstack Flow's document approvals. After implementation-scope approval, execute tasks autonomously through its filename routing, Per-Task Change Set, quality gate, commit, and Post-Implementation Review.
+
+Apply a security-reviewer finding only when leaving it unresolved would violate an explicit governing requirement or repository rule, or leave a concrete material security failure in the actual reachable trust model. The violated requirement, rule, or failure defines implementation scope: route the smallest correction that resolves it, treating the reviewer's suggestion as one candidate implementation.
 
 External evidence, prototypes, and repository environment preparation remain conditional under the canonical flow. A missing optional input does not create a stop.
 

.agents/skills/recipe-implement/SKILL.md

@@ -50,9 +50,11 @@ Enter autonomous execution when the subagents-orchestration-guide `Authority Gra
 
 For a fullstack task set, apply the Fullstack Flow filename routing exposed by `subagents-orchestration-guide`. For a single-layer task set, use the executor and quality fixer selected by `affectedLayers`. Execute each task through the canonical autonomous task cycle.
 
-### Post-Implementation Verification (After All Tasks Complete)
+### Post-Implementation Review (After All Tasks Complete)
 
-Apply subagents-orchestration-guide `Post-Implementation Verification Pass/Fail Criteria` to the actual repository changes and governing documents. Use the active Small task file as the security source when no durable document exists. Resolve required fixes through the normal task cycle and `Post-Verification Rerun Rule`.
+Apply subagents-orchestration-guide `Post-Implementation Review` to the actual repository changes and governing documents. Use the active Small task file as the governing source when no durable document exists. Resolve required fixes through the normal task cycle.
+
+Apply a security-reviewer finding only when leaving it unresolved would violate an explicit governing requirement or repository rule, or leave a concrete material security failure in the actual reachable trust model. The violated requirement, rule, or failure defines implementation scope: route the smallest correction that resolves it, treating the reviewer's suggestion as one candidate implementation.
 
 ### Test Information Communication
 Verify acceptance-test-generator artifact paths and pass them to work-planner.

.agents/skills/recipe-quality-profile/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: recipe-quality-profile
+description: "Proposes and, after user confirmation, creates or maintains docs/project-context/quality.yaml from repository-specific review requirements. Use when asked to generate or update a repository quality profile."
+---
+
+## Required Skills [LOAD BEFORE EXECUTION]
+
+1. `llm-friendly-context` — make each generated condition unambiguous, executable, and observable
+2. `coding-rules` — distinguish repository-specific policy from general code quality knowledge
+
+## Purpose
+
+Establish repository-specific code-quality acceptance conditions with the user, then create or update `docs/project-context/quality.yaml`. Create `docs/project-context/` when the directory is absent.
+
+Target repository and, when a profile already exists, requested policy change: $ARGUMENTS
+
+## Profile Contract
+
+Use this shape:
+
+```yaml
+version: 1
+review_dimensions:
+  - id: stable-kebab-case-id
+    applies_when: Observable condition that makes this repository rule relevant to a change.
+    pass: Observable accepted state to verify.
+    evidence:
+      - "repository/path: section, identifier, or contract"
+```
+
+Each dimension represents one repository-specific decision. `id` identifies it across reviews, `applies_when` limits its review surface, `pass` defines acceptance, and `evidence` records why the repository owns the rule.
+
+## Authoring Flow
+
+1. Resolve the target repository and read its existing `docs/project-context/quality.yaml` when present. When a profile exists without a requested policy change, ask for the intended change and keep the profile unchanged.
+2. Establish candidate dimensions before deciding profile content:
+   - For initial creation, derive candidates from acceptance conditions that repository instructions, contributor documentation, CI, manifests and scripts, schemas and public contracts, tests, or established implementation patterns express or enforce.
+   - For an update, translate the requested policy change into candidate additions, changes, or removals. Match it to the current dimension that owns the same policy when one exists and preserve other dimensions as the proposed unchanged set.
+3. State a candidate `applies_when` and `pass`, then identify the repository claims that must hold for that criterion to mean what it says. Inspect supporting and contradicting evidence, following declarations, workflows, contracts, tests, and usages wherever their difference could change the candidate's applicability, accepted state, or ownership.
+4. Compare the candidate with the current profile and repository evidence. Record duplicated policy ownership, contradictory accepted states under overlapping `applies_when` conditions, conflicting evidence, and current accepted behavior that the candidate would newly reject. Separate repository facts from policy choices that only the user can make.
+5. Retain a candidate for the proposal only when its failure would change implementation acceptance and every repository fact it depends on is supported by cited evidence. Present remaining policy choices for user confirmation. When a required repository fact cannot be established, report the exact evidence needed and omit that candidate from the proposal. A general language or framework concern qualifies when repository evidence adds a distinct local rule. Express each retained dimension as one positive observable `pass` condition with the narrowest useful `applies_when` boundary, and consolidate dimensions that would produce the same finding and correction.
+6. Before writing, present the proposed additions, changes, and removals; confirm that other dimensions remain unchanged; show the supporting and contradicting evidence for each proposed modification; and state every unresolved policy choice with its effect on review acceptance. **[STOP — BLOCKING]** Keep the repository unchanged until the user explicitly confirms a proposal with no unresolved choices.
+7. When the user's response changes a proposed criterion or resolves a policy choice, repeat its repository comparison and present the revised proposal for confirmation. After confirmation, write only the confirmed profile content.
+8. Read the resulting YAML and verify version `1`, unique IDs, all four dimension fields, positive observable pass conditions, readable evidence references, and consistency with the confirmed proposal.
+
+When no repository-specific dimension survives this process and no profile exists, report that no profile content is supported and leave the repository unchanged.
+
+## Result
+
+Before confirmation, report:
+
+- proposed additions, changes, and removals, plus confirmation that other dimensions remain unchanged;
+- supporting and contradicting repository evidence for each proposed modification, plus exact evidence needed for any candidate that cannot yet be proposed;
+- policy choices requiring the user's decision and how each choice changes review acceptance.
+
+After confirmation, report:
+
+- profile path and whether it was created, updated, or left unchanged;
+- dimensions added, changed, or removed;
+- evidence used for each changed dimension;
+- an exact validation limitation when the profile could not be verified.
+
+## Completion Check
+
+- [ ] `llm-friendly-context` was read before authoring criteria
+- [ ] Every dimension changes a review decision and cites repository or user-policy evidence
+- [ ] Conditions are positive, observable, and limited by `applies_when`
+- [ ] The profile contains only repository-specific acceptance conditions
+- [ ] Candidate criteria were compared with supporting and contradicting repository evidence
+- [ ] The user confirmed the proposed profile content before any repository write
+- [ ] Dimensions outside the requested update remain unchanged and the resulting set is internally consistent
+- [ ] The written profile satisfies the Profile Contract

.agents/skills/recipe-quality-profile/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "recipe-quality-profile"
+  short_description: "Create or maintain repository review policy"
+  default_prompt: "Use $recipe-quality-profile to generate or update the quality profile for: "
+
+policy:
+  allow_implicit_invocation: false