WOR-67: migrate violation evidence to defect semantics

AGENTS.md

@@ -9,7 +9,7 @@ purpose:
   - Orchestration skills: `orch-*`, provide skills for feature-implementation orchestration, including evidence gathering, specification/plan creation, execution instruction, verifying, etc.
   - General conception:
   - `work_bundle_root`: installed WorkBundle toolkit source; it owns builtin skills, rules, references, and toolkit helper code.
-  - `work_bundle_config_root`: user runtime state at `~/.work-bundle/`; it owns bootstrap, global registries, global rules, and violation state.
+  - `work_bundle_config_root`: user runtime state at `~/.work-bundle/`; it owns bootstrap, global registries, global rules, and defect state.
   - `workspace_root`: authority root for one managed workspace; it owns `.work-bundle/`, root `AGENTS.md`, `script/`, and `credentials/`; in multi-repository mode it also owns managed repository member paths.
   - `project_root`: root of one concrete source repository checkout that agents inspect, edit, test, and commit. In multi-repository mode it is a child of `workspace_root`; in single-repository mode it equals `workspace_root`.
 

references/assets/orchestration/contract/handoff-executor-result-v1.md

@@ -92,10 +92,10 @@ convergence:
   checks:
     - "exact command or inspection"
 
-violation_closure:
+defect_closure:
   status: not-applicable | carried-to-review | completed | blocked
   evidence:
-    - violation-id-or-path
+    - defect-id-or-path
   note: "Review-only closure evidence; executors do not delete evidence."
 
 unresolved:
@@ -171,7 +171,7 @@ allocation_evidence:
 - `contract_decoupling` is required when a task is marked contract-decoupled or depends on a common contract group.
 - `barrier` is required when a task is a barrier participant or convergence owner.
 - `convergence` is required when the task owns post-barrier joint debug, integration checks, or cross-branch validation.
-- `violation_closure` is required when a review task closes or carries specification-included violation evidence.
+- `defect_closure` is required when a review task closes or carries specification-included defect evidence.
 - `unresolved` is included only when blockers or issues remain.
 - `task_fit_check` is required for completed and partial task results. It records the assigned task, result `clean|repaired|unresolved|skipped`, artifacts checked, and meaningful findings.
 - `acceptance_review` is required when the task contract requires review. A review-required task cannot become `Completed` until the verdict is `accept`.
@@ -214,7 +214,7 @@ Compact handoffs must not weaken safety gates:
 - `knowledge_disposition.action` is exactly `none`, `update`, `supersede`, or `reclassify`; reasons and affected authority must not name knowledge paths or any `ks-*` skill, and review owns any approved persistence follow-up.
 - Contract-decoupled handoffs must show validation against the common contract and accepted prior handoffs, not sibling in-progress implementation.
 - Barrier handoffs must show whether the participant reached the barrier or blocked before convergence work is scheduled.
-- Violation closure handoffs must use review-owned lifecycle evidence and must not delete violation evidence files.
+- Defect closure handoffs must use review-owned lifecycle evidence and must not delete defect evidence files.
 
 ## Format Guidance
 

references/assets/orchestration/contract/specification-v1.md

@@ -61,7 +61,7 @@ Metadata blockers may block source inspection, impact traversal, planning, or ex
 
 Source Context must include project metadata preflight evidence or a blocking open question that explains why metadata preflight could not establish a trustworthy branch, commit, registry, and CodeGraph baseline.
 
-For WorkBundle project specifications, Source Context must include related active violation registry evidence when the current scope matches active violations. Each included violation records ID, severity, deviation summary, related scope, required resolution, and expected review closure. Exact-current-work conflicts may be specification-owned instead of requiring separate new violation evidence.
+For WorkBundle project specifications, Source Context must include related active defect registry evidence when the current scope matches active defects. Each included defect records ID, severity, deviation summary, related scope, required resolution, and expected review closure. Exact-current-work conflicts may be specification-owned instead of requiring separate new defect evidence.
 
 When no supporting authority note exists for the user purpose, record the retrieval gap and analyze the purpose from user input and repository evidence. Use Design Interrogation only for unresolved design intent that cannot be answered from current evidence.
 
@@ -146,7 +146,7 @@ Do not add a lifecycle stage, force a recommendation, or use a universal product
 - **REQ-SHELL-003**: Revise draft requirements after bounded evidence gathering instead of silently replacing them.
 - **REQ-META-001**: Run project metadata preflight after shell creation and before broad repository evidence gathering; block on missing metadata, branch mismatch, stale baseline affecting evidence trust, registry contradiction, or inconsistent CodeGraph state.
 - **REQ-KG-001**: Run bounded durable-knowledge gateway retrieval for material new findings or requests even when repository metadata blockers prevent source inspection, provided the gateway is accessible.
-- **REQ-VIOL-001**: For WorkBundle project scopes, inspect related active violation registry evidence and carry matching violations into Source Context or Open Questions with review closure expectations.
+- **REQ-DEF-001**: For WorkBundle project scopes, inspect related active defect registry evidence and carry matching defects into Source Context or Open Questions with review closure expectations.
 
 ## 6. Interfaces & Data Contracts
 
@@ -226,7 +226,7 @@ Every open question must include:
 | Required resolution | yes |
 | Advised options | yes |
 
-Candidate, background, blocked, draft, proposed, stale, opposing, or otherwise non-authority durable knowledge must not become requirement text. When material, record it as rationale, traceability, conflict evidence, or open-question input. Related active violations that affect the specification scope are blocking open questions unless the user or accepted evidence resolves them. Non-authority or opposing evidence is blocking only when the unresolved decision affects implementation or review safety.
+Candidate, background, blocked, draft, proposed, stale, opposing, or otherwise non-authority durable knowledge must not become requirement text. When material, record it as rationale, traceability, conflict evidence, or open-question input. Related active defects that affect the specification scope are blocking open questions unless the user or accepted evidence resolves them. Non-authority or opposing evidence is blocking only when the unresolved decision affects implementation or review safety.
 
 ## 12. Knowledge Base Update
 
@@ -262,7 +262,7 @@ Do not instruct specification authors or executors to write durable knowledge di
 - The source context records neutral cross-stage retrieval anchors or a retrieval gap, and any named retrieval policy is used only for classification/output grouping.
 - The specification carries accepted authority context forward so downstream planning and execution do not need to read `.work-bundle/knowledge/`.
 - The specification records project metadata preflight evidence including `working_branch`, `last_commit_id`, branch status, baseline status, and CodeGraph no-index fallback when applicable.
-- WorkBundle project specifications record related active violations and expected review closure when applicable.
+- WorkBundle project specifications record related active defects and expected review closure when applicable.
 - Material non-authority or opposing evidence is visible without shaping requirements unless resolved by user decision or accepted authority.
 
 ## 15. Quality Gate

references/assets/template/AGENTS.md

@@ -6,7 +6,7 @@ purpose:
   - Orchestration skills: `orch-*`, provide skills for feature-implementation orchestration, including evidence gathering, specification/plan creation, execution instruction, verifying, etc.
   - General conception:
   - `work_bundle_root`: installed WorkBundle toolkit source; it owns builtin skills, rules, references, and toolkit helper code.
-  - `work_bundle_config_root`: user runtime state at `~/.work-bundle/`; it owns bootstrap, global registries, global rules, and violation state.
+  - `work_bundle_config_root`: user runtime state at `~/.work-bundle/`; it owns bootstrap, global registries, global rules, and defect state.
   - `workspace_root`: authority root for one managed workspace; it owns `.work-bundle/`, root `AGENTS.md`, `script/`, and `credentials/`; in multi-repository mode it also owns managed repository member paths.
   - `project_root`: root of one concrete source repository checkout that agents inspect, edit, test, and commit. In multi-repository mode it is a child of `workspace_root`; in single-repository mode it equals `workspace_root`.
 

references/evals/orchestration/evals.json

@@ -231,14 +231,14 @@
     },
     {
       "id": 39,
-      "prompt": "Create a WorkBundle implementation specification for a scope that matches active violation registry entries.",
-      "expected_output": "Selects create-specification, inspects the WorkBundle violation registry without browsing .work-bundle/knowledge/**, includes related active violations as blocking Open Questions with severity, related scope, required resolution, and expected review closure, and treats exact-current-work conflicts as specification-owned when applicable.",
+      "prompt": "Create a WorkBundle implementation specification for a scope that matches active defect registry entries.",
+      "expected_output": "Selects create-specification, inspects the WorkBundle defect registry without browsing .work-bundle/knowledge/**, includes related active defects as blocking Open Questions with severity, related scope, required resolution, and expected review closure, and treats exact-current-work conflicts as specification-owned when applicable.",
       "files": []
     },
     {
       "id": 40,
-      "prompt": "Review a completed WorkBundle plan whose source specification included active violation evidence and whose implementation passed unblocked validation.",
-      "expected_output": "Selects review-plan, validates implementation and handoff evidence, closes resolved specification-included violations with the approved lifecycle action before archive, records violation_closure evidence, does not delete evidence files, keeps unrelated violations untouched, and blocks archive if included violation closure cannot be completed.",
+      "prompt": "Review a completed WorkBundle plan whose source specification included active defect evidence and whose implementation passed unblocked validation.",
+      "expected_output": "Selects review-plan, validates implementation and handoff evidence, closes resolved specification-included defects with the approved lifecycle action before archive, records defect_closure evidence, does not delete evidence files, keeps unrelated defects untouched, and blocks archive if included defect closure cannot be completed.",
       "files": []
     },
     {

rules/index.yaml

@@ -206,6 +206,23 @@ rules:
     load: conditional
     requires:
       - rule-work-bundle-security-exclusion
+  - id: wb-defect-evaluation
+    path: work-bundle/wb-defect-evaluation.md
+    applies_when:
+      - a conflict, violation, error, failed validation, contradictory workflow behavior, user interruption, or user correction occurs during WorkBundle-guided work
+      - visible task evidence suggests a WorkBundle skill, rule, script, specification, plan, handoff, workflow contract, or toolkit execution surface may have caused or contributed to the problem
+      - an agent must decide whether an observed problem is work-bundle-scoped, project-scoped, mixed, or undetermined before creating defect evidence or reporting a blocker
+    enforcement: must
+    load: conditional
+    requires: []
+  - id: wb-defect-evidence
+    path: work-bundle/wb-defect-evidence.md
+    applies_when:
+      - the Work Bundle rule is visible in AGENTS.md and any conflict, confliction, violation, contradiction, or user correction occurs
+      - the Work Bundle rule is visible in AGENTS.md and the session needs a visible entry point for defect evaluation and first-observed evidence routing
+    enforcement: must
+    load: always
+    requires: []
   - id: wb-migrate-to-multi-repository
     path: work-bundle/wb-migrate-to-multi-repository.md
     applies_when:
@@ -259,20 +276,3 @@ rules:
     enforcement: must
     load: conditional
     requires: []
-  - id: wb-violation-evaluation
-    path: work-bundle/wb-violation-evaluation.md
-    applies_when:
-      - a conflict, violation, error, failed validation, contradictory workflow behavior, user interruption, or user correction occurs during WorkBundle-guided work
-      - visible task evidence suggests a WorkBundle skill, rule, script, specification, plan, handoff, workflow contract, or toolkit execution surface may have caused or contributed to the problem
-      - an agent must decide whether an observed problem is work-bundle-scoped, project-scoped, mixed, or undetermined before creating violation evidence or reporting a blocker
-    enforcement: must
-    load: conditional
-    requires: []
-  - id: wb-violation-evidence
-    path: work-bundle/wb-violation-evidence.md
-    applies_when:
-      - the Work Bundle rule is visible in AGENTS.md and any conflict, confliction, violation, contradiction, or user correction occurs
-      - the Work Bundle rule is visible in AGENTS.md and the session needs a visible entry point for violation evaluation and first-observed evidence routing
-    enforcement: must
-    load: always
-    requires: []

rules/orchestration/orch-handoff-required.md

@@ -32,7 +32,7 @@ Require compact executor-result handoffs before reporting execution complete or
 - For contract-decoupled task handoffs, include compact `contract_decoupling` evidence: common contract group, common contracts checked, validation scope, `peer_implementation_validation_used: false`, and forbidden peer validation result.
 - For barrier participants, include compact `barrier` evidence with barrier id, participant role, readiness `reached|blocked`, and whether convergence remains pending.
 - For convergence owners, include compact `barrier` and `convergence` evidence showing every participant completed or blocked with executor-result handoffs before joint validation began.
-- For review handoffs or review-adjacent executor results that carry specification-included violations, include `violation_closure` evidence only as review-owned lifecycle evidence or carry-forward status; executors must not delete violation evidence.
+- For review handoffs or review-adjacent executor results that carry specification-included defects, include `defect_closure` evidence only as review-owned lifecycle evidence or carry-forward status; executors must not delete defect evidence.
 - Do not report execution complete while drift or gaps remain within task scope. Record out-of-scope findings as unresolved issues and block completion when they prevent conformance with the assigned artifacts.
 - Keep executor-result handoffs on carried spec, plan, phase, task, declared handoff, and task-scoped source or test context only; do not retrieve durable knowledge during execution-completion handoffs.
 - Update `.work-bundle/orchestration/handoff/index.jsonl` with id, type, status, path, project, timestamps, and related spec, plan, phase, and task links when helper/index support is available for the handoff format.

rules/orchestration/orch-open-questions.md

@@ -22,7 +22,7 @@ Expose uncertainty explicitly in specifications and block planning while blockin
 - Treat material draft, proposed, conflicting, stale, missing-evidence, candidate, background, or blocked knowledge as a blocking open question when it affects requirements, architecture, workflow, API, persistence, validation, execution behavior, or conflict with user purpose.
 - Record material opposite, candidate, background, blocked, draft, proposed, conflicting, stale, or missing-evidence inputs in Open Questions when they affect the specification scope, even when they are not blocking.
 - Decide blocking status from unresolved impact to requirements, architecture, workflow, policy, API, persistence, validation, execution behavior, review closure, or user-purpose safety; evidence class or polarity alone is not a blocker.
-- For WorkBundle project specifications, record related active violation registry evidence as blocking Open Questions unless the user or accepted evidence resolves them for the current scope.
+- For WorkBundle project specifications, record related active defect registry evidence as blocking Open Questions unless the user or accepted evidence resolves them for the current scope.
 - Treat non-material unsettled knowledge as out of `create-specification` resolution scope; it may remain source context or be omitted, but it must not block planning.
 - When no relevant uncertainty exists, state `None for this specification scope.` in the Open Questions section.
 - Inspect the source specification `Open Questions` section first before creating any implementation plan.
@@ -47,7 +47,7 @@ Expose uncertainty explicitly in specifications and block planning while blockin
 
 - Confirm the specification includes an Open Questions section with ID, source, scope, blocking classification, required resolution, and advised options for each listed uncertainty, or an explicit none statement.
 - Confirm material non-authority or opposing evidence is visible when scope-affecting but does not shape requirements and is not marked blocking solely by evidence class or polarity.
-- Confirm WorkBundle related active violations are carried as blocking Open Questions with review closure expectations unless resolved for the current scope.
+- Confirm WorkBundle related active defects are carried as blocking Open Questions with review closure expectations unless resolved for the current scope.
 - Confirm planning either cites no unresolved questions or returns the required refusal table before any plan artifact is written.
 - Confirm no plan task depends on silently inferred answers to listed open questions.
 

rules/orchestration/orch-review-completion.md

@@ -42,7 +42,7 @@ Keep final review focused on whether the WorkBundle workflow completed correctly
 - Permit `new_feature` or `uncovered_fixture` with an empty `invariant_trace` only when `negative_evidence` proves no matching original user request or accepted specification invariant and no plan, handoff, or produced-commit contradiction.
 - Route `owning_repair` to the first broken artifact: task or acceptance criterion present plus implementation miss means task repair and re-review; accepted specification present plus plan omission means plan repair and resume from the owning step; original-request invariant omitted or contradicted by the accepted specification means specification repair. Only after those cases are excluded may a residual class stand.
 - Keep classification agent-owned and evidence-linked. A helper may require and structurally validate the record but must not decide the semantic class.
-- Keep same-scope specification-owned handling authoritative for a first-observed classification defect. Persist separate WorkBundle violation evidence only after `wb-violation-evaluation` classifies the finding as work-bundle-scoped or mixed and same-scope specification-owned handling no longer applies.
+- Keep same-scope specification-owned handling authoritative for a first-observed classification defect. Persist separate WorkBundle defect evidence only after `wb-defect-evaluation` classifies the finding as work-bundle-scoped or mixed and same-scope specification-owned handling no longer applies.
 
 ## Must Not