takt 0.33.0 → 0.33.2

package/builtins/en/facets/instructions/architecture-audit-plan.md

@@ -0,0 +1,13 @@
+Audit the project architecture before making changes.
+
+**What to do:**
+1. Enumerate the main modules, layers, boundaries, and public entry points using Read, Glob, and Grep
+2. Identify the dependency directions, shared abstractions, and major call chains
+3. Build an audit scope that covers all modules relevant to structure, ownership, and wiring
+4. Highlight modules with higher architectural risk (boundary leaks, giant files, scattered logic, coupling hotspots)
+5. Prepare an audit order that reviews the highest-risk modules first
+
+**Important:**
+- Start from full module and boundary enumeration, not from a few suspicious files
+- Focus on structure and wiring, not style-only comments
+- If the architecture cannot be inferred from code alone, state the missing evidence explicitly

package/builtins/en/facets/instructions/architecture-audit-review.md

@@ -0,0 +1,15 @@
+Re-audit the modules or boundaries that were judged insufficient in the previous architecture audit.
+
+**Important:** Refer to these reports:
+- Plan report: {report:01-architecture-audit-plan.md}
+- Audit report: {report:02-architecture-audit.md}
+
+**What to do:**
+1. Read the flagged modules, boundaries, and call chains in full
+2. Re-check the structural claims and identify what was previously skipped or weakly evidenced
+3. Update the audit result with concrete file evidence, explicit scope coverage, and missing-item reasons where applicable
+
+**Strictly prohibited:**
+- Modifying production code
+- Claiming a boundary or dependency direction is valid without file evidence
+- Skipping a flagged module because it "looks standard"

package/builtins/en/facets/instructions/architecture-audit-supervise.md

@@ -0,0 +1,14 @@
+Verify the completeness and quality of the architecture audit itself.
+
+**Important:** Refer to these reports:
+- Plan report: {report:01-architecture-audit-plan.md}
+- Audit report: {report:02-architecture-audit.md}
+
+**Verification procedure:**
+1. Cross-check the module inventory from the plan against the audited modules in the audit report
+2. Reject if important modules or boundaries remain unaudited
+3. Reject if key dependency directions, wiring paths, ownership boundaries, or call chains from the plan are missing from the audit result without an explicit reason
+4. Verify the audit report includes concrete structural evidence, not just design opinions
+5. Verify the report includes the enumeration commands used and that they are sufficient to support the claimed scope
+6. Sample-read a few high-risk modules yourself to confirm the structural claims are credible
+7. Require re-audit if findings or suggested issue titles are too vague to file directly

package/builtins/en/facets/instructions/architecture-audit-team-leader.md

@@ -0,0 +1,22 @@
+Decompose the architecture audit, assign modules to each part, and execute in parallel.
+
+**Important:** Refer to the plan report: {report:01-architecture-audit-plan.md}
+
+**What to do:**
+1. Review the module inventory and architectural risk areas from the plan report
+2. Split the audit into 3 groups by module or boundary
+3. Assign exclusive ownership to each part so every relevant module is audited once
+
+**Each part's instruction MUST include:**
+- Assigned module and file list
+- The boundaries and call chains to verify
+- Required audit procedure:
+  1. Read the assigned files in full
+  2. Trace dependency direction, entry points, and shared abstractions
+  3. Record structural findings with concrete file evidence
+- Completion criteria: every assigned module has been audited and all findings are reported with evidence
+
+**Constraints:**
+- Each part is read-only
+- Do not audit files outside the assignment
+- Prefer evidence from code structure and call chains over style-only comments

package/builtins/en/facets/instructions/e2e-audit-plan.md

@@ -0,0 +1,13 @@
+Audit the target for E2E coverage before making changes.
+
+**What to do:**
+1. Enumerate all user entry points, major routes, task flows, and failure paths from the codebase
+2. Read the existing E2E tests and map which flows and scenarios are already covered
+3. Build a complete list of auditable user flows and scenario variants
+4. Identify missing E2E scenarios and prioritize them by user impact and regression risk
+5. Prepare an implementation order that covers the highest-risk missing scenarios first
+
+**Important:**
+- Start from complete route and flow enumeration, not from a few obvious pages
+- Include unhappy paths, permission differences, and recovery paths when relevant
+- If a flow cannot be audited from local code and tests alone, state the missing evidence explicitly

package/builtins/en/facets/instructions/e2e-audit-review.md

@@ -0,0 +1,16 @@
+Re-audit the routes or scenarios that were judged insufficient in the previous E2E audit.
+
+**Important:** Review the supervisor's verification results and understand:
+- Unaudited flows or scenarios
+- Coverage claims lacking evidence
+- Specific feedback on issue quality or scope
+
+**What to do:**
+1. Read the flagged route-related code and corresponding E2E tests in full
+2. Re-check the coverage claims for the flagged scenarios and identify what was previously skipped or weakly evidenced
+3. Update the audit result in issue-ready form with concrete evidence, explicit scope coverage, and missing-item reasons where applicable
+
+**Strictly prohibited:**
+- Modifying E2E tests or production code
+- Claiming a scenario is covered without citing the actual test evidence
+- Skipping a flagged route because it "looks fine"

package/builtins/en/facets/instructions/e2e-audit-supervise.md

@@ -0,0 +1,11 @@
+Verify the completeness and quality of the E2E audit itself.
+
+**Important:** Refer to the audit plan report: {report:01-e2e-audit-plan.md}
+
+**Verification procedure:**
+1. Cross-check the full route and flow inventory in the plan against the audited scenarios in the audit report
+2. Reject if any important entry point, user flow, unhappy path, permission variant, or recovery path from the plan is missing from the audit result without an explicit reason
+3. Verify the audit report includes concrete evidence for covered and missing scenarios, not just high-level claims
+4. Verify the report includes the enumeration commands used and that they are sufficient to support the claimed scope
+5. Sample-read a few high-risk routes and corresponding tests yourself to validate the coverage claims
+6. Require re-audit if issue titles, priorities, or recommended actions are too vague to be filed directly

package/builtins/en/facets/instructions/e2e-audit-team-leader.md

@@ -0,0 +1,22 @@
+Decompose the E2E audit, assign flows to each part, and execute in parallel.
+
+**Important:** Refer to the plan report: {report:01-e2e-audit-plan.md}
+
+**What to do:**
+1. Review the user flow list, existing scenarios, and risk areas from the plan report
+2. Split the audit into 3 groups by feature area or route cluster
+3. Assign exclusive ownership so every audited flow is reviewed once
+
+**Each part's instruction MUST include:**
+- Assigned routes, entry points, and corresponding E2E files
+- The happy paths, failure paths, and permission variants to verify
+- Required audit procedure:
+  1. Read the relevant code for the assigned flows
+  2. Read the corresponding E2E tests in full
+  3. Record covered and missing scenarios with concrete evidence
+- Completion criteria: every assigned flow has been audited and findings are reported in issue-ready form
+
+**Constraints:**
+- Each part is read-only
+- Do not modify E2E tests or production code
+- Do not audit routes outside the assignment

package/builtins/en/facets/instructions/review-arch.md

@@ -28,5 +28,9 @@ Review {report:coder-decisions.md} to understand the recorded design decisions.
 1. First, extract previous open findings and preliminarily classify as `new / persists / resolved`
 2. Review the change diff and detect issues based on the architecture and design criteria above
    - Cross-check changes against REJECT criteria tables defined in knowledge
+   - If you find a DRY violation, require it to be fixed
+   - Before proposing a fix, verify that the consolidation target fits existing responsibility boundaries, contracts, and public API shape
+   - If you require a new wrapper, helper, or public API, explain why that abstraction target is the natural one
+   - If the proposed abstraction goes beyond the task spec or plan, state why the additional scope is necessary and justified
 3. For each detected issue, classify as blocking/non-blocking based on Policy's scope determination table and judgment rules
 4. If there is even one blocking issue (`new` or `persists`), judge as REJECT

package/builtins/en/facets/instructions/review-qa.md

@@ -23,5 +23,7 @@ Review {report:coder-decisions.md} to understand the recorded design decisions.
 1. First, extract previous open findings and preliminarily classify as `new / persists / resolved`
 2. Review the change diff and detect issues based on the quality assurance criteria above
    - Cross-check changes against REJECT criteria tables defined in knowledge
+   - Even if tests pass, verify whether any additional change outside the task or plan is justified
+   - If review-driven follow-up changes expand the design, evaluate whether that extra change is actually necessary
 3. For each detected issue, classify as blocking/non-blocking based on Policy's scope determination table and judgment rules
 4. If there is even one blocking issue (`new` or `persists`), judge as REJECT

package/builtins/en/facets/instructions/review-security.md

@@ -4,15 +4,28 @@ Review the changes from a security perspective. Check for the following vulnerab
 - Data exposure risks
 - Cryptographic weaknesses
 
+**Primary sources to review:**
+- Review `order.md` to understand requirements and prohibitions.
+- Review `plan.md` to understand intended scope and design direction.
+- Review {report:coder-decisions.md} to understand the recorded design decisions.
+- Do not dismiss documented decisions as FP by default. Re-evaluate them against `order.md`, `plan.md`, and the actual code.
 
-**Design decisions reference:**
-Review {report:coder-decisions.md} to understand the recorded design decisions.
-- Do not flag intentionally documented decisions as FP
-- However, also evaluate whether the design decisions themselves are sound, and flag any problems
+**Important:**
+- Do not treat documented precedence rules, extension points, or configuration override behavior as vulnerabilities by themselves.
+- Do not assume that removing an interactive confirmation or warning automatically means a security boundary regression.
+- To issue a blocking finding, make the exploit path concrete: who controls what input, and what newly becomes possible.
 
 ## Judgment Procedure
 
-1. Review the change diff and detect issues based on the security criteria above
-   - Cross-check changes against REJECT criteria tables defined in knowledge
-2. For each detected issue, classify as blocking/non-blocking based on Policy's scope determination table and judgment rules
-3. If there is even one blocking issue, judge as REJECT
+1. Cross-check `order.md`, `plan.md`, `coder-decisions.md`, and the actual code to determine whether the behavior is intentional product behavior
+2. Review the change diff and extract issue candidates by cross-checking changes against REJECT criteria in knowledge
+3. For each candidate, verify the concrete exploit path
+   - Which actor controls the input or configuration
+   - Whether the change enables new privilege, data access, code execution, or prompt modification
+   - Whether the impact exceeds the existing documented precedence or extension model
+4. When configuration precedence, local/global shadowing, or non-interactive selection is involved, additionally verify:
+   - Whether the behavior is intended by `order.md` or `plan.md`
+   - Whether explicit selectors or arguments already make the user's intent clear
+   - Whether there is an actual trust-boundary break or new attack capability, rather than merely an override relationship
+5. For each detected issue, classify it as blocking or non-blocking based on the Policy scope table and judgment rules
+6. If there is even one blocking issue, judge as REJECT

package/builtins/en/facets/instructions/supervise.md

@@ -5,7 +5,13 @@ Verify existing evidence for tests, builds, and functional checks, then perform
    - Does implementation match the plan?
    - Were all review movement findings properly addressed?
    - Was the original task objective achieved?
-2. Whether each task spec requirement has been achieved
+   - Are prior review findings themselves valid against the task spec, plan, and actual code?
+2. Verify the task spec, plan, and decision history as primary sources
+   - Read `order.md` and extract required behavior and prohibitions
+   - Read `plan.md` and confirm intended approach and scope
+   - Read `coder-decisions.md` and confirm why the implementation moved in that direction
+   - Do not treat prior review conclusions as authoritative unless they align with all three and the code
+3. Whether each task spec requirement has been achieved
    - Extract requirements one by one from the task spec
    - If a single sentence contains multiple conditions or paths, split it into the smallest independently verifiable units
      - Example: treat `global/project` as separate requirements
@@ -17,14 +23,19 @@ Verify existing evidence for tests, builds, and functional checks, then perform
    - Evidence must cover the full content of the requirement row
    - Do not rely on the plan report's judgment; independently verify each requirement
    - If any requirement is unfulfilled, REJECT
-3. Handling tests, builds, and functional checks
+4. Re-evaluate prior review findings
+   - Re-check each `new / persists / resolved` finding against the task spec, `plan.md`, `coder-decisions.md`, and actual code
+   - If a finding does not hold in code, classify it as `false_positive`
+   - If a finding holds technically but pushes work beyond the task objective or justified scope, classify it as `overreach`
+   - Do not leave `false_positive` / `overreach` reasoning implicit
+5. Handling tests, builds, and functional checks
    - Do not assume this movement will rerun commands
    - Use only evidence available in this run, such as execution logs, reports, or CI results
    - If evidence is missing, mark the item as unverified
    - If report text conflicts with execution evidence, call out the inconsistency explicitly
 
 **Report verification:** Read all reports in the Report Directory and
-check for any unaddressed improvement suggestions.
+check whether any blocking finding remains unresolved and whether those findings are themselves valid.
 
 **Validation output contract:**
 ```markdown
@@ -45,6 +56,14 @@ Extract requirements from the task spec and verify each one individually against
 - ✅ without evidence is invalid (must verify against actual code)
 - Do not rely on plan report's judgment; independently verify each requirement
 
+## Re-evaluation of Prior Findings
+| finding_id | Prior status | Re-evaluation | Evidence |
+|------------|--------------|---------------|----------|
+| {id} | new / persists / resolved | valid / false_positive / overreach | `src/file.ts:42`, `reports/plan.md` |
+
+- If final judgment differs from prior review conclusions, explain why with evidence
+- If marking `false_positive` or `overreach`, state whether it conflicts with the task objective, the plan, or both
+
 ## Verification Summary
 | Item | Status | Verification method |
 |------|--------|-------------------|

package/builtins/en/facets/instructions/unit-audit-plan.md

@@ -0,0 +1,13 @@
+Audit the target for unit test coverage before making changes.
+
+**What to do:**
+1. Enumerate the target production files, exported APIs, internal branches, error paths, boundary checks, and state transitions using Read, Glob, and Grep
+2. Read existing unit tests and map which behaviors are already covered
+3. Build a complete inventory of auditable behaviors for each target file
+4. Identify missing unit tests and prioritize them by regression risk
+5. Prepare an implementation order that covers the highest-risk gaps first
+
+**Important:**
+- Start from complete enumeration, not from a few obvious gaps
+- Do not stop after identifying a handful of missing tests
+- If the scope is unclear, state exactly which files or behaviors need clarification

package/builtins/en/facets/instructions/unit-audit-review.md

@@ -0,0 +1,16 @@
+Re-audit the files or behaviors that were judged insufficient in the previous unit audit.
+
+**Important:** Review the supervisor's verification results and understand:
+- Unaudited files or behaviors
+- Coverage claims lacking evidence
+- Specific feedback on issue quality or scope
+
+**What to do:**
+1. Read the flagged production files and corresponding tests in full
+2. Re-check the coverage claims for the flagged behaviors and identify what was previously skipped or weakly evidenced
+3. Update the audit result in issue-ready form with concrete evidence, explicit scope coverage, and missing-item reasons where applicable
+
+**Strictly prohibited:**
+- Modifying tests or production code
+- Claiming a behavior is covered without citing the actual test evidence
+- Skipping a flagged file or behavior because it "looks fine"

package/builtins/en/facets/instructions/unit-audit-supervise.md

@@ -0,0 +1,11 @@
+Verify the completeness and quality of the unit test audit itself.
+
+**Important:** Refer to the audit plan report: {report:01-unit-audit-plan.md}
+
+**Verification procedure:**
+1. Cross-check the full target inventory in the plan against the audited files and behaviors in the audit report
+2. Reject if any production file, exported API, branch, error path, boundary check, or state transition from the plan is missing from the audit result without an explicit reason
+3. Verify the audit report includes concrete evidence for both covered and missing behaviors, not just conclusions
+4. Verify the report includes the enumeration commands used and that they are sufficient to support the claimed scope
+5. Sample-read a few target production files and corresponding tests yourself to confirm the coverage claims are credible
+6. Require re-audit if issue titles, priorities, or recommended actions are too vague to be filed directly

package/builtins/en/facets/instructions/unit-audit-team-leader.md

@@ -0,0 +1,22 @@
+Decompose the unit audit, assign files to each part, and execute in parallel.
+
+**Important:** Refer to the plan report: {report:01-unit-audit-plan.md}
+
+**What to do:**
+1. Review the production file list, existing tests, and audited behavior inventory from the plan report
+2. Split the audit into 3 groups by module or test area
+3. Assign exclusive ownership so every target file and behavior is audited once
+
+**Each part's instruction MUST include:**
+- Assigned production files and corresponding test files
+- The behaviors, branches, error paths, and boundary checks to verify
+- Required audit procedure:
+  1. Read every assigned production file in full
+  2. Read the corresponding unit tests in full
+  3. Record covered and missing behaviors with concrete file evidence
+- Completion criteria: every assigned target has been audited and findings are reported in issue-ready form
+
+**Constraints:**
+- Each part is read-only
+- Do not modify tests or production code
+- Do not audit files outside the assignment

package/builtins/en/facets/knowledge/security.md

@@ -18,6 +18,30 @@ Require extra scrutiny:
 - Error messages (AI may expose internal details)
 - Config files (AI may use dangerous defaults from training data)
 
+## Precedence Resolution, Override, and Trust Boundaries
+
+Resolving multiple configuration or definition sources by precedence, intentional override behavior, and extension points are not vulnerabilities by themselves. The real question is whether the change breaks a trust boundary or gives a lower-trust actor a new attack capability.
+
+| Criteria | Verdict |
+|----------|---------|
+| Behavior follows documented precedence rules within the same user and trust level | OK |
+| An explicit selector or argument chooses the target and resolution still follows the documented precedence model | OK |
+| A higher-precedence definition wins over a lower-precedence one, but stays within the documented customization contract and does not expand privileges or data access | Warning at most. Normally not REJECT |
+| A lower-trust actor can override a higher-trust setting or definition and thereby gain new code execution, modify higher-trust assets, access data, or bypass authorization | REJECT |
+| An interactive confirmation step is removed, but explicit selection already makes intent unambiguous and the trust boundary is unchanged | OK |
+| An interactive confirmation step was the only trust-boundary control, and removing it silently enables lower-trust override | May be REJECT. Make the attack preconditions and impact concrete |
+
+### How to Evaluate
+
+To treat precedence resolution or override behavior as a vulnerability, make all of the following concrete:
+
+- Who the lower-trust actor is and what input or configuration they control
+- What the higher-trust asset is
+- What becomes possible only after this change
+- Why that behavior exceeds the documented precedence or extension model
+
+If the product already allows behavior to be customized through multiple scoped definition files or configuration sources, enabling selection among definitions at the same trust level is usually not a new attack capability by itself.
+
 ## Injection Attacks
 
 **SQL Injection:**

package/builtins/en/facets/output-contracts/architecture-audit-plan.md

@@ -0,0 +1,26 @@
+```markdown
+# Architecture Audit Plan
+
+## Enumeration Evidence
+- Commands used:
+  - `rg ...`
+  - `rg --files ...`
+- Scope notes:
+  - {how modules, layers, boundaries, and entry points were enumerated}
+
+## Module Inventory
+| # | Module / Layer | Key Files | Responsibility | Main Boundaries | Risk |
+|---|----------------|-----------|----------------|-----------------|------|
+| 1 | {module or layer} | `src/file.ts` | {primary responsibility} | {boundary summary} | High / Medium / Low |
+
+## Audit Targets
+| # | Module / Layer | What to Verify | Priority |
+|---|----------------|----------------|----------|
+| 1 | {module or layer} | {dependency direction, wiring, ownership, abstraction} | High / Medium / Low |
+
+## Audit Order
+- {ordered module review plan}
+
+## Clarifications / Risks
+- {open questions or constraints}
+```

package/builtins/en/facets/output-contracts/architecture-audit.md

@@ -0,0 +1,38 @@
+```markdown
+# Architecture Audit Report
+
+## Result: APPROVE / IMPROVE / REJECT
+
+## Enumeration Evidence
+- Commands used:
+  - `rg ...`
+  - `rg --files ...`
+- Coverage notes:
+  - {how you confirmed the full module and boundary set was audited}
+
+## Audit Scope
+| # | Module / Layer | Audited | Key Files | Boundaries Verified |
+|---|----------------|---------|-----------|---------------------|
+| 1 | {module or layer} | ✅ | `src/file.ts` | {boundary summary} |
+
+## Findings
+| # | Severity | Category | Location | Issue | Recommended Fix |
+|---|----------|----------|----------|-------|-----------------|
+| 1 | High / Medium / Low | boundary / coupling / wiring / dead-code | `src/file.ts:42` | {issue description} | {fix suggestion} |
+
+## Modules with No Blocking Issues
+- {modules audited with no blocking findings}
+
+## Suggested Issue Titles
+1. {Issue title}
+2. {Issue title}
+
+## Follow-up Notes
+- {non-blocking observations or constraints}
+- {explicit reasons for any intentionally unaudited item}
+```
+
+**Cognitive load reduction rules:**
+- APPROVE → Scope table only (15 lines max)
+- IMPROVE → Scope table + relevant findings only
+- REJECT → Include only blocking findings and impacted modules

package/builtins/en/facets/output-contracts/{security-audit.md → audit-security.md}

@@ -5,6 +5,13 @@
 
 ## Severity: None / Low / Medium / High / Critical
 
+## Enumeration Evidence
+- Commands used:
+  - `rg ...`
+  - `rg --files ...`
+- Coverage notes:
+  - {how you confirmed the full file set was audited}
+
 ## Audit Scope
 | # | File | Audited | Risk Classification |
 |---|------|---------|-------------------|
@@ -18,9 +25,17 @@
 ## Files with No Issues
 - {list of files where no issues were detected}
 
+## Suggested Issue Titles
+1. {Issue title}
+2. {Issue title}
+
 ## Recommendations (non-blocking)
 - {security improvement suggestions}
 
+## Notes
+- {constraints, assumptions, or audit limits}
+- {explicit reasons for any intentionally unaudited item}
+
 ## REJECT Criteria
 - REJECT if one or more High or Critical issues exist
 ```

package/builtins/en/facets/output-contracts/e2e-audit-plan.md

@@ -0,0 +1,26 @@
+```markdown
+# E2E Audit Plan
+
+## Enumeration Evidence
+- Commands used:
+  - `rg ...`
+  - `rg --files ...`
+- Scope notes:
+  - {how routes, flows, and E2E specs were enumerated}
+
+## Audited User Flows
+| # | Area | Route / Entry | Existing Scenarios | Coverage Status | Risk |
+|---|------|---------------|--------------------|-----------------|------|
+| 1 | {feature area} | {route or entry point} | {existing test names} | Covered / Partial / Missing | High / Medium / Low |
+
+## Missing Scenarios
+| # | Area | Scenario | Priority | Planned Test Location |
+|---|------|----------|----------|-----------------------|
+| 1 | {feature area} | {missing scenario} | High / Medium / Low | `e2e/example.spec.ts` |
+
+## Audit Order
+- {ordered audit plan}
+
+## Clarifications / Risks
+- {open questions or constraints}
+```

package/builtins/en/facets/output-contracts/e2e-audit.md

@@ -0,0 +1,41 @@
+```markdown
+# E2E Audit Report
+
+## Result: APPROVE / IMPROVE / REJECT
+
+## Summary
+{1-3 sentences summarizing the flow coverage situation}
+
+## Enumeration Evidence
+- Commands used:
+  - `rg ...`
+  - `rg --files ...`
+- Coverage notes:
+  - {how you confirmed the full flow set was audited}
+
+## Scope
+| # | Area | Route / Entry | Existing Scenarios | Coverage Status | Risk |
+|---|------|---------------|--------------------|-----------------|------|
+| 1 | {feature area} | {route or entry point} | {existing test names} | Covered / Partial / Missing | High / Medium / Low |
+
+## Findings
+| # | Priority | Area | Location | Gap | Recommended Action |
+|---|----------|------|----------|-----|--------------------|
+| 1 | High / Medium / Low | e2e-testing | `e2e/example.spec.ts` / `src/page.tsx:42` | {missing or weakly tested scenario} | {issue-ready action} |
+
+## No-Issue Areas
+- {flows confirmed as adequately covered}
+
+## Suggested Issue Titles
+1. {Issue title}
+2. {Issue title}
+
+## Notes
+- {constraints, assumptions, or audit limits}
+- {explicit reasons for any intentionally unaudited item}
+```
+
+**Cognitive load reduction rules:**
+- APPROVE → Summary + Scope only
+- IMPROVE → Include only relevant gaps
+- REJECT → Include only blocking or high-priority gaps

package/builtins/en/facets/output-contracts/unit-audit-plan.md

@@ -0,0 +1,26 @@
+```markdown
+# Unit Test Audit Plan
+
+## Enumeration Evidence
+- Commands used:
+  - `rg ...`
+  - `rg --files ...`
+- Scope notes:
+  - {how target production files and tests were enumerated}
+
+## Audit Scope
+| # | Production File | Existing Test Files | Audited Behaviors / Branches | Coverage Status |
+|---|-----------------|---------------------|------------------------------|-----------------|
+| 1 | `src/file.ts` | `src/__tests__/file.test.ts` | {exported APIs, branches, errors, boundaries} | Covered / Partial / Missing |
+
+## Missing Test Cases
+| # | Production File | Behavior / Branch | Priority | Planned Test Location |
+|---|-----------------|-------------------|----------|-----------------------|
+| 1 | `src/file.ts` | {missing behavior} | High / Medium / Low | `src/__tests__/file.test.ts` |
+
+## Audit Order
+- {ordered audit plan}
+
+## Clarifications / Risks
+- {open questions or constraints}
+```

package/builtins/en/facets/output-contracts/unit-audit.md

@@ -0,0 +1,41 @@
+```markdown
+# Unit Audit Report
+
+## Result: APPROVE / IMPROVE / REJECT
+
+## Summary
+{1-3 sentences summarizing the coverage situation}
+
+## Enumeration Evidence
+- Commands used:
+  - `rg ...`
+  - `rg --files ...`
+- Coverage notes:
+  - {how you confirmed the full target set was audited}
+
+## Scope
+| # | Production File | Existing Test Files | Audited Behaviors | Coverage Status |
+|---|-----------------|---------------------|-------------------|-----------------|
+| 1 | `src/file.ts` | `src/__tests__/file.test.ts` | {key behaviors} | Covered / Partial / Missing |
+
+## Findings
+| # | Priority | Area | Location | Gap | Recommended Action |
+|---|----------|------|----------|-----|--------------------|
+| 1 | High / Medium / Low | unit-testing | `src/file.ts:42` | {missing or weakly tested behavior} | {issue-ready action} |
+
+## No-Issue Areas
+- {files or behaviors confirmed as adequately covered}
+
+## Suggested Issue Titles
+1. {Issue title}
+2. {Issue title}
+
+## Notes
+- {constraints, assumptions, or audit limits}
+- {explicit reasons for any intentionally unaudited item}
+```
+
+**Cognitive load reduction rules:**
+- APPROVE → Summary + Scope only
+- IMPROVE → Include only relevant gaps
+- REJECT → Include only blocking or high-priority gaps

package/builtins/en/facets/personas/conductor.md

@@ -11,7 +11,8 @@ Read the provided information (report, agent response, or conversation log) and
 1. Review the information provided in the instruction (report/response/conversation log)
 2. Identify the judgment result (APPROVE/REJECT, etc.) or work outcome from the information
 3. Output the corresponding tag in one line according to the decision criteria table
-4. **If you cannot determine, clearly state "Cannot determine"**
+4. If the provided information contains internal contradictions, do not output a tag; clearly state "Cannot determine"
+5. **If you cannot determine, clearly state "Cannot determine"**
 
 ## What NOT to do
 
@@ -19,6 +20,7 @@ Read the provided information (report, agent response, or conversation log) and
 - Do NOT use tools
 - Do NOT check additional files or analyze code
 - Do NOT modify or expand the provided information
+- Do NOT force a tag when the report contradicts itself
 
 ## Output Format
 
@@ -37,6 +39,13 @@ If any of the following applies, clearly state "Cannot determine":
 - The provided information does not match any of the judgment criteria
 - Multiple criteria may apply
 - Insufficient information
+- The report's conclusion conflicts with its own evidence
+
+Examples of contradictions:
+- `Result: APPROVE` but unresolved `new` / `persists` findings remain
+- A requirements table contains ❌ while the result says APPROVE
+- The report claims verification was completed while evidence is explicitly missing
+- The re-evaluation of prior findings conflicts with the final conclusion
 
 Example output:
 
@@ -44,4 +53,4 @@ Example output:
 Cannot determine: Insufficient information
 ```
 
-**Important:** Respect the result shown in the provided information as-is and output the corresponding tag number. If uncertain, do NOT guess - state "Cannot determine" instead.
+**Important:** Respect the result shown in the provided information as-is only when the report is internally consistent. If uncertain, do NOT guess - state "Cannot determine" instead.

package/builtins/en/facets/personas/security-reviewer.md

@@ -40,3 +40,6 @@ Security cannot be retrofitted. It must be built in from the design stage; "we'l
 - How to fix it
 
 **Remember**: You are the security gatekeeper. Never let vulnerable code pass.
+
+Also distinguish intended product precedence and extension behavior from actual trust-boundary breaks.
+Do not label something a vulnerability based only on the presence or absence of a confirmation prompt; make the attacker, control point, and impact concrete.