contextcompass 2.15.0__py3-none-any.whl

contextcompass_cli/_package/agent_onboarding/default/engineer/policies/engineer_quality_policy.md

@@ -0,0 +1,33 @@
+
+
+# engineer_quality_policy
+
+Purpose
+- Establish the quality bar for engineer changes.
+
+Policy
+- Every touched function/class must have a rich docstring aligned with the behavior.
+- Tests must be added or updated for behavioral changes.
+- Avoid drive-by refactors; limit edits to the requested scope.
+- If a class implements cleanup, assume it is not used after cleanup completes.
+- Default cleanup posture for owned references is delete/remove the live field
+  surface; retain `None` only when the contract explicitly needs a post-cleanup
+  tombstone field.
+- Prefer `check_cleaned()` fail-fast behavior when the contract requires active state.
+- Use `if self._cleaned: return` only when non-throwing behavior is explicit contract.
+- Do not add `None` guards on internally owned fields unless optionality is proven.
+Unknowns Gate
+- Apply the canonical policy in
+  `agent_onboarding/default/general/skills/unknowns_gate_reference.md`.
+- UNKNOWN is still the default for unevidenced claims in engineer quality reviews.
+- Quality findings must cite concrete file/symbol evidence or remain UNKNOWN.
+- Do not treat failing tests, naming patterns, or historical assumptions as
+  contract evidence without direct source verification.
+
+Exceptions
+- Only allowed with explicit user approval, documented in the response.
+
+References
+- `AGENTS.MD`
+- `agent_onboarding/default/general/skills/unknowns_gate_reference.md`
+

contextcompass_cli/_package/agent_onboarding/default/engineer/skills/context_protocol.md

@@ -0,0 +1,70 @@
+
+
+# context_protocol
+
+Purpose
+- Make the system documents the primary way you NAVIGATE: they turn "somewhere in
+  this repository" into a short list of files worth opening.
+- Keep the code authoritative for what the system actually DOES. The documents
+  describe intent as of the moment somebody wrote it down; the code is what runs.
+
+When to use
+- Before any code edits, investigations, or architectural changes.
+
+Required flow - descend the hierarchy, do not enter in the middle
+1. `system_docs/src_architecture.md` - which part of the system. Baseline read;
+   you already hold it.
+2. `system_docs/src_components_index.md` - look up the subsystem name the
+   architecture gave you. Take the section name and range.
+3. `system_docs/src_components.md` - **slice** that section. It gives you the
+   component's responsibilities, owned state, and its `Key Files (C1)`.
+4. `system_docs/src_graph_index.md` - look up the node names the component named.
+5. `system_docs/src_graph.md` - **slice** those nodes for wiring: ownership,
+   creation, publication, validation, borrowing, callers.
+6. **The code.** Open the files the graph just handed you and read them.
+
+Every step is a lookup keyed on a name the previous step produced. That is why the
+order matters: enter at the graph with no name in hand and you are searching tens of
+thousands of lines for something you cannot yet describe.
+
+The index is the ENTRY POINT to a large document, not a fallback for when something
+goes wrong. `src_components.md` and `src_graph.md` are never read whole - they are
+sliced through their indexes, every time. See
+`agent_onboarding/default/engineer/skills/src_graph_usage.md`.
+- For system-impacting changes, apply the mandatory gate in
+  `agent_onboarding/default/engineer/skills/patch_framework_gating.md` before
+  implementation.
+- For patch-lane work, follow
+  `agent_onboarding/default/engineer/skills/patch_artifact_consumption.md`
+  before code edits.
+- Review `attention_board.md` first, then open the linked active ticket(s) for current intent.
+- **Read the code you are about to change.** Always. The documents told you which
+  file; they did not tell you what that file does today.
+- If a document and the source disagree, the source wins and the document is stale.
+  Record the contradiction - it is a finding, not a detail to smooth over - and fix
+  or file it.
+
+Rules
+- Always prefer documented context over assumptions. Prefer the source over both.
+- Treat UNKNOWN as default until evidence is attached. A document is evidence of
+  intent; only the source is evidence of behaviour.
+- Keep architecture/components docs in sync with actual boundaries.
+- Read `src_components.md` and `src_graph.md` by slice through their indexes. Never
+  whole. That is a rule about HOW, not WHETHER - slice them freely and often.
+- Read what the task needs and no more. These documents scale with the repository;
+  loading all of them is not thoroughness, it is a spent context budget. See
+  `agent_onboarding/default/general/skills/context_window_budget.md`.
+- Block implementation when patch-framework entry-gate artifacts are missing for
+  system-impacting work.
+- If a doc is missing, create it before implementing related changes.
+
+Precedence
+- This protocol and `agent_onboarding/default/engineer/SKILLS.MD` define how system
+  documents are read. **A workflow does not get to override it.** A workflow may say
+  which documents a lane cares about; it may not instruct you to read a large
+  document whole, to skip an index, or to treat the raw document as the primary
+  surface. If one does, follow the hierarchy and say the workflow is stale.
+
+Examples
+- `agent_onboarding/default/general/README.md`
+

contextcompass_cli/_package/agent_onboarding/default/engineer/skills/documentation_standards.md

@@ -0,0 +1,120 @@
+
+
+# Documentation Standards (Skill)
+
+## Purpose
+Architecture and components docs must be deep enough to reorient from a blank slate
+without relying on memory, oral tradition, or "obvious" assumptions.
+
+These standards exist so *agents* (human or AI) can safely extend the system without inventing behavior.
+
+## Non-Negotiables (Hardlines)
+- **No handwaving.** Every claim must be grounded in source evidence or marked as **UNKNOWN**.
+- **Explicit entrypoints and flows.** If it's core behavior, show how it is entered and how it executes.
+- **Ownership + lifecycle clarity.** Who creates it, who owns it, how it is cleaned up, and in what order.
+- **Concurrency is first-class.** Document locks, queues, gates, thread-affinity rules, and failure modes.
+- **Consistency across layers.** C4 architecture and C3/C2/C1 components must not contradict.
+- **Diagrams are required.** Maintain ASCII + Mermaid for key flows.
+
+## Core Rules
+- No handwaving. Every claim must be grounded in source evidence or marked as unknown.
+- Use explicit entrypoints, flows, and ownership boundaries.
+- Record lifecycle and cleanup order for each core component.
+- Capture invariants, failure modes, and concurrency constraints.
+- Keep C4 (architecture) and C3/C2/C1 (components) consistent.
+- Maintain ASCII and Mermaid diagrams for key flows.
+
+## Evidence Discipline
+What counts as evidence:
+- A concrete file + symbol reference: `src/path/file.py:Class.method` or `src/path/file.py:function`
+- A reference to a previously approved doc section that was itself code-grounded
+
+What **does not** count as evidence:
+- "Typical framework behavior"
+- "Probably"
+- Naming conventions, patterns, or vibes
+
+### Required behavior when evidence is missing
+- Write **UNKNOWN** explicitly.
+- Add the item to an **Unknowns** section with:
+  - why it matters,
+  - where to investigate (file + symbol),
+  - and status (uninvestigated / investigating / blocked).
+
+### Inline evidence style (recommended)
+Use one of these patterns inside the text:
+- `EVIDENCE: src/.../file.py:Symbol`
+- `UNKNOWN: ... (investigate src/.../file.py:Symbol)`
+
+## Required Sections
+
+### Architecture Docs (C4)
+Required sections (minimum):
+- Scope and Intent
+- System Context and Boundaries
+- Entrypoints and Boot Sequence
+- Major component responsibilities and interactions
+- Ownership, lifecycle, and cleanup rules
+- Invariants and failure modes
+- Evidence and information sources
+
+Strongly recommended additions:
+- Operational playbook (bring-up + teardown)
+- Troubleshooting section (common failure modes -> where to look)
+- Diagram legend (how to interpret optional vs core subsystems)
+
+### Component Docs (C3/C2/C1)
+Required sections (minimum):
+- C3 components with responsibilities and contracts
+- C2 subcomponents with wiring and data structures
+- C1 code map for entrypoints and core files
+- Method-level call flows for core behaviors
+- Wiring tables / registry keys for runtime lookups
+
+Strongly recommended additions:
+- Registry "quick reference" for common string keys and defaults
+- Ownership matrix (who owns what; who may call what)
+- Cleanup cascade (parent -> child teardown order)
+
+### Patch Docs (Temporary, When Patch Lane Is Active)
+Required minimums for patch docs under `system_docs/patches/active/<patch_id>/`:
+- `architecture_patch.md`: objective/non-goals, changed components, invariants,
+  interface deltas, migration order, rollback, ticket coverage matrix.
+- `component_patch_<component>.md`: before/after behavior, interface deltas,
+  state/failure deltas, dependency/ordering, validation expectations.
+- `code_description_patch_<component>.md` (conditional): control flow,
+  edge/error semantics, invariants/idempotency, explicit non-goals.
+
+Gate rule
+- For system-impacting work, implementation should not start until required
+  patch docs exist and are linked from the active ticket.
+
+## Metadata & Status (If Present)
+When a doc includes a Metadata block:
+- Update the `Updated:` date whenever you change behavior descriptions.
+- Keep `Status:` honest (draft / current / deprecated).
+- If the doc is a "durable context" artifact, prefer **append-only enrichment** over rewriting history.
+
+## Diagram Standards
+- Provide **ASCII** for terminal scanning and diffs.
+- Provide **Mermaid** for higher fidelity.
+- Label edges with verbs when it improves clarity (e.g., "creates", "owns", "enqueues").
+- Show optional subsystems with dashed arrows/edges.
+- Don't let diagrams become "art": clarity > completeness.
+
+## Consistency Rules (Across Docs)
+- Names and terms should match across C4 and C3/C2/C1 docs (e.g., "Spectrum", "CommandCenter", etc.).
+- If you rename a component, update:
+  - component catalog,
+  - diagrams,
+  - wiring tables,
+  - and code map references.
+
+## Review Checklist (Before You Call It "Current")
+- [ ] No unverified claims (or they are marked UNKNOWN)
+- [ ] Core flows have method-level call sequences
+- [ ] Ownership/lifecycle/cleanup ordering is explicit
+- [ ] Concurrency constraints are called out where relevant
+- [ ] ASCII + Mermaid diagrams reflect the written description
+- [ ] Information Sources list includes every file used as evidence
+

contextcompass_cli/_package/agent_onboarding/default/engineer/skills/engineer_execution.md

@@ -0,0 +1,62 @@
+
+
+# engineer_execution
+
+Purpose
+- Define how engineer agents plan and implement code changes in this
+  repository.
+
+Core rules
+- Follow `AGENTS.MD` and the shared baseline skills in
+  `agent_onboarding/default/general/`.
+- Propose a plan before editing; keep scope tight and reviewable.
+- Enforce `patch_framework_gating.md` for system-impacting changes before any
+  implementation edits.
+- Consume required patch artifacts using
+  `patch_artifact_consumption.md` before editing system-impacting code.
+- Follow repository SQL rules in `AGENTS.MD` when touching SQL tools.
+- Update docstrings for every touched function/class and add tests for
+  behavioral changes.
+- Keep scratch ideas and todos under `user_defined/`. That directory exists, is
+  yours outright, and no tool writes to it in any mode - create whatever subfolders
+  you need. Earlier revisions of this skill named `workspace/agent/`, which the
+  package has never shipped and which no lane policy protects, so scratch written
+  there was swept on the next cleanup.
+- Promote durable plans and execution artifacts into `tickets/epics/`,
+  `tickets/stories/`, `tickets/tasks/`, and their completed folders.
+
+Preferred workflow
+1) Clarify the goal, constraints, and affected files.
+2) Route from `attention_board.md` to the active ticket and follow the Ticket
+   Microcycle.
+3) If scope is system-impacting, verify patch-framework entry gate artifacts
+   exist and are linked before editing code.
+4) Build and record patch-section to implementation/validation mapping in ticket
+   notes.
+5) Review existing docstrings and contracts in the target modules.
+6) Implement changes with small, cohesive functions and explicit error handling.
+7) Run tests (or report "Not run" with reasoning).
+8) Summarize changes and list follow-ups.
+
+Artifact discipline (engineer)
+- Ideas/opinions/todo: `user_defined/` only.
+- Plans and scope control: use `templates/` and create tickets in
+  `tickets/epics/`, `tickets/stories/`, `tickets/tasks/`.
+- For system-impacting changes under patch framework:
+  - maintain active patch docs under `system_docs/patches/active/<patch_id>/`,
+  - link patch docs from active tickets,
+  - complete merge+cleanup closure gates before marking work done.
+- Status updates: keep `attention_board.md` current and append detailed
+  findings to ticket `## Notes`.
+- Closures: move completed tickets to their matching completed folder with
+  summary + date.
+- Convert approved todos into tickets instead of leaving them in scratch.
+
+Examples
+- `agent_onboarding/default/engineer/examples/artifact_workflow.md`
+
+References
+- `AGENTS.MD`
+- `agent_onboarding/default/general/skills/workflow.md`
+- `agent_onboarding/default/engineer/skills/patch_framework_gating.md`
+- `agent_onboarding/default/engineer/skills/patch_artifact_consumption.md`

contextcompass_cli/_package/agent_onboarding/default/engineer/skills/package_maintenance.md

@@ -0,0 +1,195 @@
+# package_maintenance
+
+Purpose
+- Define how to clean an install back to shipping state and how to upgrade one
+  to a newer version of the package without destroying local work.
+
+When this applies
+- You are preparing the package for distribution.
+- One project's content has ended up inside another install.
+- A newer version of Context Compass needs to be rolled into an existing repo.
+
+This is not the ticket cleanup workflow. `agent_onboarding/default/general/workflows/cleanup_context_compass.md`
+closes tickets and syncs boards. The tools here delete and replace files.
+
+## The manifest is the contract
+
+`MANIFEST.md` records, for every file the package ships: its path, its ownership
+class, and its sha256. It is generated, never hand-edited - a hand-maintained
+version stamp drifts the moment someone forgets to bump it, and a stamp that
+lies looks exactly like one that does not.
+
+```bash
+python context_compass/tools/package_manifest.py --root context_compass --version 2.1.0
+python context_compass/tools/package_manifest.py --root context_compass --check
+```
+
+Regenerate it in the same pass as any change to package files. `--check` reports
+added, removed and changed paths without writing.
+
+## Ownership classes
+
+| class | who owns it | cleanup | update |
+| --- | --- | --- | --- |
+| `PACKAGE` | the library | restore | replace |
+| `RESET` | the project (tickets, artifacts, system docs, project instructions) | reset mode only | never touched |
+| `INSTANCE` | the project (`agent_onboarding/user_defined/`) | never touched | never touched |
+| `LIVE` | shared: package block + project rows | block reset | block swapped |
+| `CONFIG` | shared: package schema + project values | left alone | keys merged |
+
+Class is assigned by longest path prefix, so a `PACKAGE` directory can still hold
+a `RESET` subtree. That is not hypothetical - a real cleanup found five foreign
+scripts sitting inside `tools/`, which is package-owned.
+
+## Cleaning an install
+
+```bash
+python context_compass/tools/cleanup_context_compass.py \
+    --target  path/to/install/context_compass \
+    --reference path/to/clean/context_compass \
+    --mode repair --check
+```
+
+Two modes, because "clean" means two different things:
+
+- **`--mode repair`** fixes a broken install and leaves the project's work alone.
+  Use this on a live repository.
+- **`--mode reset`** returns the working lanes to shipping state. Use this when
+  preparing a release or stripping one project's content out.
+
+Reset empties `system_docs/`, `tickets/` and `artifacts/`. On a live repository
+that deletes the architecture maps, tickets and findings the project wrote.
+**Run `--check` first, every time.** The tool refuses to act without `--apply`.
+
+`system_docs/` ships EMPTY - the package seeds no architecture, component, test
+or graph document, because a placeholder in a live lane gets read as repository
+truth. `examples/` is the shape reference. Neither tool ever writes into
+`system_docs/` or `agent_onboarding/user_defined/`.
+
+### Cutting a release from a working install
+
+`--mode reset` clears the working lanes but deliberately leaves role overlays
+under `agent_onboarding/user_defined/` alone, because they belong to whoever
+wrote them. A release should not ship them either, so there is one explicit
+opt-in:
+
+```bash
+python context_compass/tools/cleanup_context_compass.py \
+    --target ./release/context_compass --reference ./context_compass \
+    --mode reset --purge-user-defined --check
+```
+
+`--purge-user-defined` is never implied by `--mode reset`. Deleting someone's
+role because they asked to tidy a lane would break the invariant the class
+exists to protect, so it has to be asked for by name. Without the flag the tool
+still tells you which overlays it found and which roles they belong to.
+
+### Config drift
+
+Config is never rewritten by cleanup. When its manifest hash does not match, the
+tool reports which top-level keys you added, removed, or retuned against the
+shipped defaults:
+
+```
+config    your `config/context_compass_config.yaml` differs from stock:
+            keys you added:      our_own_section
+            values you changed:  system_of_record, workflow
+```
+
+That is the answer to "how does mine differ from stock", and it is why the
+manifest bothers to record a hash for a file it never enforces. A hash nothing
+checks is the same dead weight as a version stamp nothing bumps.
+
+Order of operations inside the tool matters and is deliberate: remove foreign
+files, prune directories that are now empty, then re-materialise every manifest
+path. Pruning last leaves stale empty directories; pruning without the final
+restore loses lanes whose only content was a `.gitkeep`.
+
+## Upgrading an install
+
+```bash
+python context_compass/tools/update_context_compass.py \
+    --install path/to/install/context_compass \
+    --new     path/to/new/context_compass \
+    --check
+```
+
+The decision is made from three hashes, not one:
+
+| current vs shipped | new vs shipped | verdict |
+| --- | --- | --- |
+| same | changed | replace |
+| same | same | skip |
+| changed | same | keep the local edit |
+| changed | changed | **conflict** - reported, not touched |
+
+One hash tells you a file changed. It cannot tell you who changed it, and that is
+the only thing that decides whether overwriting is safe. Without the shipped hash
+from the install's own manifest, rows three and four are indistinguishable from
+row one, so you either clobber local edits or never update anything.
+
+Conflicts are never merged automatically. A merge is a guess, and a wrong guess
+destroys work quietly. Resolve them by hand, or pass `--force-conflicts` to take
+the new version and lose the local edit knowingly.
+
+### Upgrading an install that predates the manifest
+
+An older install has no `MANIFEST.md`, so there are no shipped hashes and a local
+edit is indistinguishable from an upstream change. The tool does not guess. It
+reports **every** differing file as a conflict, still skips files that match, and
+still adds new ones:
+
+```
+NOTE: <install> has no MANIFEST.md, so this is its first manifest-aware upgrade.
+  replace   0
+  skip    331   already current
+  conflict  3   BOTH changed - not touched
+```
+
+Review the conflicts, then re-run with `--force-conflicts` to take the package
+version wholesale. Either way the upgrade writes the new manifest, so the next
+upgrade is a normal three-hash comparison and this only happens once.
+
+Project-owned lanes are untouched throughout: `system_docs/`, `tickets/`,
+`artifacts/` and `user_defined/` survive a forced upgrade intact.
+
+## Live files and managed blocks
+
+The boards carry a package-owned directive above project-owned rows. The package
+region is delimited:
+
+```markdown
+<!-- BEGIN MANAGED: ReminderDirective -->
+...package text, replaced wholesale on upgrade...
+<!-- END MANAGED: ReminderDirective -->
+```
+
+Only that region is swapped. Routing rows survive an upgrade. This is the same
+marker convention as patch document `ENTRY` markers, deliberately - one dialect,
+one parser. Malformed or unterminated markers refuse the operation rather than
+guessing where the boundary was.
+
+## Config
+
+Merged key by key, never swapped wholesale. New top-level keys arrive with their
+package defaults and their explanatory comments; a value already set is never
+overwritten; keys dropped upstream are reported rather than deleted.
+
+The merge is deliberately not a YAML round-trip. Parsing and re-emitting would
+reformat the file and drop the user's comments, which is a worse outcome than
+leaving a key unmerged and saying so.
+
+## Anti-patterns
+
+- Running `--mode reset` on a live repository without `--check` first.
+- Comparing paths instead of content. A path-only diff reports a tree as correct
+  while another project's boards and system documents sit at package paths.
+- Hand-editing `MANIFEST.md`.
+- Treating a conflict as something to resolve by picking the newer file.
+- Upgrading without regenerating the manifest afterwards, which leaves the
+  install claiming a version it is not.
+
+References
+- `agent_onboarding/default/general/workflows/cleanup_context_compass.md` (ticket
+  cleanup, a different operation with a similar name)
+- `agent_onboarding/default/engineer/skills/staleness_protocol.md`

contextcompass_cli/_package/agent_onboarding/default/engineer/skills/patch_artifact_consumption.md

@@ -0,0 +1,68 @@
+# patch_artifact_consumption
+
+Purpose
+- Define how `engineer` consumes patch artifacts before and during
+  implementation.
+- Make architecture/component/code-description patches executable inputs rather
+  than optional background context.
+
+Scope
+- Applies when `patch_framework_gating.md` is triggered for system-impacting
+  work.
+- Covers consumption behavior only (authoring belongs to `design_engineer`).
+
+Required read order (non-negotiable)
+1) `system_docs/patches/active/<patch_id>/architecture_patch.md`
+2) `system_docs/patches/active/<patch_id>/component_patch_<component>.md`
+   for each changed component
+3) `system_docs/patches/active/<patch_id>/code_description_patch_<component>.md`
+   when present or required by trigger rules
+
+Consumption contract
+- Extract from `architecture_patch.md`:
+  - boundary/interface deltas,
+  - cross-component invariants,
+  - migration order,
+  - rollback constraints.
+- Extract from each `component_patch_<component>.md`:
+  - before/after behavior,
+  - state/failure deltas,
+  - validation expectations,
+  - dependency ordering.
+- Extract from each `code_description_patch_<component>.md`:
+  - control flow commitments,
+  - edge/error semantics,
+  - idempotency expectations,
+  - explicit non-goals.
+
+Implementation mapping rule
+- Before code edits, write a concise ticket-note mapping:
+  - patch section -> implementation step -> validation step.
+- If mapping cannot be produced from available artifacts, raise `BLOCKER`.
+
+Mandatory stop conditions
+- Missing required patch artifact.
+- Patch docs conflict with each other.
+- Patch docs conflict with canonical architecture/component docs and no accepted
+  override note exists.
+- Patch unknowns are unresolved for the target code path.
+
+During implementation
+- Keep edits within patch-defined boundaries.
+- If scope expands, update patch docs and ticket links first.
+- Do not silently "fix forward" patch-contract conflicts in code.
+
+Before closure
+- Verify implemented behavior matches patch contracts.
+- Record validation evidence against patch expectations.
+- Complete merge-and-cleanup gates from `patch_framework_gating.md`.
+
+Manual validation expectation
+- Confirm required artifacts exist for the patch id.
+- Confirm ticket artifact links and consumption mapping notes are present.
+- Confirm closure evidence maps implemented behavior back to patch contracts.
+
+References
+- `agent_onboarding/default/engineer/skills/patch_framework_gating.md`
+- `agent_onboarding/default/engineer/skills/engineer_execution.md`
+- `agent_onboarding/default/general/skills/workflow.md`

contextcompass_cli/_package/agent_onboarding/default/engineer/skills/patch_framework_gating.md

@@ -0,0 +1,72 @@
+
+# patch_framework_gating
+
+Purpose
+- Define mandatory engineer gates for using patch-framework artifacts during
+  system-impacting changes.
+- Ensure implementation work is blocked until required patch contracts exist.
+- Enforce required artifact consumption behavior via
+  `patch_artifact_consumption.md`.
+
+When this gate applies
+- The task changes architecture/component boundaries, lifecycle behavior,
+  policy/gating behavior, or cross-component interaction contracts.
+- The task changes code that requires updates to `system_docs/src_architecture.md`
+  or `system_docs/src_components.md`.
+- The task changes source wiring/ownership enough that
+  `system_docs/src_graph.md` must be refreshed.
+- The user explicitly requests patch-based planning/governance.
+
+Non-negotiable entry gate
+- Do not implement system-impacting code changes until all required artifacts
+  exist for the active patch id and are linked from the active ticket.
+- If artifacts are missing, mark `BLOCKED` and create/update patch artifacts
+  first.
+- Do not implement until the required artifact read order is completed and
+  consumption mapping is documented in ticket notes.
+
+Required patch artifacts
+1) `system_docs/patches/active/<patch_id>/architecture_patch.md` (required)
+2) `system_docs/patches/active/<patch_id>/component_patch_<component>.md`
+   for each changed component (required)
+3) `system_docs/patches/active/<patch_id>/code_description_patch_<component>.md`
+   (conditional)
+
+`code_description_patch` required triggers
+- Complex control flow or state-machine changes.
+- New/changed policy gate pipelines.
+- Non-trivial error semantics or rollback behavior.
+- Concurrency or idempotency-sensitive changes.
+
+Engineer execution gate checklist
+- [ ] Active ticket routes this work from `attention_board.md`.
+- [ ] Patch id is explicit and stable.
+- [ ] Required patch docs exist and are ticket-linked.
+- [ ] Required read order from `patch_artifact_consumption.md` is complete.
+- [ ] Ticket notes contain patch-section to implementation/validation mapping.
+- [ ] Unknowns in patch docs are either resolved or explicitly accepted.
+- [ ] Implementation scope matches patch doc boundaries.
+
+Engineer closure gate checklist
+- [ ] Implementation evidence captured in ticket notes.
+- [ ] Durable deltas merged into canonical docs.
+- [ ] Temporary patch docs removed from `system_docs/patches/active/<patch_id>/`
+      unless an explicit retention exception is approved.
+- [ ] Attention board and artifact board synchronized.
+
+Manual validation expectation
+- Confirm required artifacts exist under
+  `system_docs/patches/active/<patch_id>/`.
+- Confirm artifact links are present in the active ticket.
+- Confirm required read-order and mapping notes are documented before
+  implementation.
+
+Failure behavior
+- If any entry/closure gate fails, stop and raise `BLOCKER` or
+  `DECISION_REQUEST` in ticket notes before continuing.
+
+References
+- `agent_onboarding/default/general/skills/ticketing.md`
+- `agent_onboarding/default/general/skills/workflow.md`
+- `agent_onboarding/default/general/skills/ticket_closure_attention_sync.md`
+- `agent_onboarding/default/engineer/skills/patch_artifact_consumption.md`