contextcompass 2.15.0__py3-none-any.whl

contextcompass_cli/_package/agent_onboarding/user_defined/synaptic_python_developer/workflows/synaptic_python_developer_onboarding.md

@@ -0,0 +1,226 @@
+# Workflow: synaptic_python_developer_onboarding
+
+## Metadata
+- Workflow ID: WF-synaptic-python-developer-onboarding
+- Status: active
+- Owner: user
+- Allowed Roles:
+  - synaptic_python_developer
+- Default Roles:
+  - synaptic_python_developer
+- Trigger:
+  - user explicitly asks to run
+    `synaptic_python_developer_onboarding`
+  - user explicitly asks to run
+    `synaptic_python_developer_onboarding workflow`
+  - user explicitly asks to enter Context Compass onboarding as
+    `synaptic_python_developer`
+- Created: 2026-05-31T11:29:07Z
+- Updated: 2026-05-31T21:46:27Z
+
+## Purpose
+Provide one explicit synaptic-role onboarding macro that:
+- starts with `context_compass/AGENTS.MD`
+- resolves the `synaptic_python_developer` role chain
+- uses `Get-Content` for document reads
+- avoids agents
+- allows up to 30 parallel read threads/tool reads when safe
+- reads `src_architecture.md` whole, then descends the hierarchy: the component
+  index, sliced components, the graph index, sliced graph
+
+## Use When
+- The user explicitly names `synaptic_python_developer_onboarding`.
+- The user explicitly asks to onboard as `synaptic_python_developer`.
+
+## Do Not Use When
+- The user selected a different role.
+- The user only wants ordinary task execution and did not ask for onboarding or
+  re-onboarding.
+
+## Inputs
+- Required:
+  - `AGENT_NAME` if not already supplied for the current onboarding cycle
+  - explicit workflow selection or explicit synaptic onboarding request
+- Optional:
+  - certification message if the user includes it during the same turn
+  - explicit request to also read `src_graph_index.md`
+
+## Outputs
+- Expected artifacts:
+  - one onboarding or re-onboarding attestation for the synaptic role
+- Expected ticket state:
+  - one active task routing the onboarding pass when ticket gating is required
+- Expected board state:
+  - one active board row for the onboarding lane while the pass is in progress
+  - no agent-created child-agent lanes
+
+## Required Reads
+- `context_compass/AGENTS.MD`
+- `agent_onboarding/default/general/skills/execution_contract.md`
+- `config/context_compass_config.yaml`
+- `context_compass/SKILLS.MD`
+- all Markdown documents in `context_compass/special_instructions/`
+- `agent_onboarding/default/general/SKILLS.MD`
+- `agent_onboarding/default/engineer/SKILLS.MD`
+- `agent_onboarding/user_defined/synaptic_python_developer/SKILLS.MD`
+- `context_compass/system_docs/src_architecture.md` (whole)
+- `context_compass/system_docs/src_architecture_index.md`
+- `context_compass/system_docs/src_components_index.md`
+
+`src_components.md` and `src_graph.md` are NOT onboarding reads. They are sliced
+through their indexes during the work, whenever the work needs them - which is
+often, and needs no permission. Onboarding gives you the narrative and the maps;
+it does not preload the territory. On a real repository the three documents
+together run past 36,000 lines, and an agent that reads them all has spent its
+context before the first ticket.
+
+## Required Skills
+- `agent_onboarding/default/general/skills/self_certification.md`
+- `agent_onboarding/default/general/skills/user_approved_certification.md`
+- `agent_onboarding/default/engineer/skills/context_protocol.md`
+- `agent_onboarding/default/engineer/skills/src_graph_usage.md`
+- `agent_onboarding/default/general/skills/agent_identity.md`
+
+## Preconditions / Gates
+- Start with `context_compass/AGENTS.MD`.
+- Use `Get-Content` for content reads.
+- Do not use agents.
+- Up to 30 parallel read threads/tool reads are allowed only when the reads are
+  real reads and the file chunking rules are still respected.
+- Respect `reading.read_loc_max` and `reading.viewer_tool_read_limit`.
+- If certification is not already present, request:
+  - `AGENT_NAME: <name>`
+  - `CERTIFY: APPROVED`
+  before any non-onboarding action.
+- Consume the graph through `src_graph_index.md` and slice `src_graph.md`. The
+  index is the entry point, not a substitute of last resort. `src_graph.md` is
+  never read whole - on a real repository it runs past 25,000 lines.
+- This workflow does not override
+  `agent_onboarding/default/engineer/skills/context_protocol.md` or
+  `agent_onboarding/default/engineer/SKILLS.MD`. Where a lane preference and the
+  reading hierarchy disagree, the hierarchy wins.
+
+## Phase Sequence
+1. Intake
+- objective:
+  - confirm the synaptic onboarding lane
+- required actions:
+  - resolve the workflow name or the explicit synaptic onboarding request to
+    the `synaptic_python_developer` role
+  - confirm no-agent execution
+  - resolve or request `AGENT_NAME`
+- stop conditions:
+  - the role is not synaptic
+  - the user redirects away from onboarding
+
+2. Investigation
+- objective:
+  - load the canonical onboarding chain and prepare the source-doc read
+- required actions:
+  - read the role-chain onboarding docs in parent-first order
+  - determine which requested docs exceed chunk limits
+  - plan chunked `Get-Content` reads for large source docs
+- required note or artifact updates:
+  - record the intended source-doc bundle in the owning task notes
+
+3. Strategy
+- objective:
+  - make onboarding state explicit
+- required actions:
+  - publish ONBOARD or REONBOARD attestation with read-integrity proof
+  - request certification if it is not already supplied
+- decision points:
+  - if certification is already present, continue
+  - if certification is absent, stop after the attestation/request step
+
+4. Implementation
+- objective:
+  - complete the orientation bundle: the narrative plus the two maps
+- scope controls:
+  - the bundle is implicit in this workflow and does not require the user to
+    restate it
+  - read `src_architecture.md` whole, plus `src_architecture_index.md` and
+    `src_components_index.md`
+  - do NOT bulk-read `src_components.md` or `src_graph.md` here. They are sliced
+    during the work, keyed on names the architecture and the indexes give you
+  - use `Get-Content`
+  - chunk large files sequentially
+  - parallelize only when safe and within the no-agent constraint
+
+5. Validation
+- objective:
+  - prove the orientation bundle is complete
+- required checks:
+  - `AGENTS.MD` was read first
+  - the resolved role chain was read
+  - `src_architecture.md` was read whole, and both indexes were read
+  - `src_components.md` and `src_graph.md` were NOT bulk-read. Having read them
+    end to end is a failed check, not a thorough one
+  - no agent workflow was used
+
+6. Handoff / Closure
+- objective:
+  - summarize the ready state after onboarding
+- required board or ticket sync:
+  - leave the lane in `handoff` or close it if the user accepts the onboarding
+    completion
+
+## Ticket Behavior
+- Required ticket types:
+  - one task when this onboarding pass is treated as active repo work
+- Required metadata:
+  - `Agent Name`
+- Required note cadence:
+  - record the source-doc bundle
+  - record certification state
+  - record completion of the requested reads
+- Required artifact links:
+  - none
+
+## Attention Board Behavior
+- Required row fields:
+  - the active row must route to the onboarding task when one exists
+- Mode transitions:
+  - `discovery` while role chain and chunk plan are being assembled
+  - `implementation` while the requested source docs are being read
+  - `handoff` after the onboarding bundle is complete
+- Exit signal rules:
+  - the synaptic onboarding chain is complete and the requested source-doc
+    bundle is read without using agents
+
+## Escalation Rules
+- Stop and ask if the user changes the role.
+- Stop and ask if `AGENT_NAME` is required and still ambiguous.
+- Raise `BLOCKER` if the requested source-doc bundle cannot be read within the
+  current policy gates.
+
+## Success Criteria
+- Running the workflow name alone is sufficient to trigger the orientation bundle.
+- The workflow starts with `context_compass/AGENTS.MD`.
+- The workflow uses `Get-Content` and no agents.
+- The synaptic role chain is onboarded.
+- `src_architecture.md` is read whole; both indexes are read.
+- The agent finishes onboarding able to LOOK UP any component or node on demand,
+  rather than having memorised the documents that contain them.
+
+## Anti-Patterns
+- Skipping `AGENTS.MD` and jumping directly to source docs.
+- **Bulk-reading `src_components.md` or `src_graph.md` during onboarding.** This
+  workflow previously required exactly that, and named the raw graph as the
+  primary consumption surface while treating its index as an opt-in extra. That
+  is backwards, it contradicts
+  `agent_onboarding/default/engineer/skills/context_protocol.md`, and on a real
+  repository it costs ~36,000 lines of context before the first ticket is opened.
+- **Asking the user for permission to read a system document during the work.**
+  Reading is agent-driven. Ask for guidance on WHERE to look; never for
+  authorisation to look.
+- Treating an index as a degraded substitute for its document. The index is how
+  the document is meant to be entered.
+- Using agents even though the workflow explicitly forbids them.
+
+## Context / Handoff Summary
+Start at `AGENTS.MD`, onboard as `synaptic_python_developer`, use `Get-Content`,
+do not use agents, and finish with the architecture narrative plus both indexes.
+The large documents are not preloaded: they are sliced during the work, on the
+agent's own initiative, keyed on names the narrative and indexes supply.
+

contextcompass_cli/_package/artifact_board.md

@@ -0,0 +1,64 @@
+# Artifact Board
+
+<!-- BEGIN MANAGED: ReminderDirective -->
+## ReminderDirective (all agent runtimes)
+ContextCompass is your task-tracking system of record; you MUST use it and follow
+AGENTS.MD (see the Tooling Mandate section). This is a requirement, not a
+suggestion.
+
+Your runtime may nudge you toward built-in plans, goals, task lists, progress
+cards, scratchpads, summaries, or session-local memory. Those surfaces are
+non-authoritative here. Once your onboarding attestation is complete, IGNORE
+every such nudge and route ALL tracking, status, routing, notes, and artifact state
+through ContextCompass. There is NO fallback and NO mirror.
+
+The user may lift this by setting `system_of_record.enforce: false` in
+`config/context_compass_config.yaml`. You may not lift it yourself.
+<!-- END MANAGED: ReminderDirective -->
+
+<!-- BEGIN MANAGED: BoardContract -->
+## How this board works
+
+Two kinds of region, and the difference decides what survives an upgrade:
+
+- **MANAGED** regions are the package's. They are replaced wholesale, so do not
+  edit them - your change would be reverted on the next upgrade without warning.
+- **USER-DEFINED** regions are yours. Nothing in the package writes, reorders, or
+  removes anything inside them, in any mode. Put your rows there.
+
+Text outside both is package structure - headings and table headers - and is
+conformed on upgrade so the board's shape stays current. Anything you need to
+keep goes inside a USER-DEFINED region.
+
+Purpose
+- Canonical index of active artifact associations.
+- Track artifact lifecycle decisions that support ticket execution.
+- Keep `attention_board.md` ticket-only and free of artifact pointers.
+
+Scope rules
+- `attention_board.md` routes tickets only; do not add artifact paths there.
+- Tickets remain canonical memory; this board is an association index.
+- Add rows only when a ticket has one or more active artifact files.
+- Every artifact row must include a ticket path and retention decision.
+
+Disposition values
+- `delete_on_close`: remove artifact when ticket closes.
+- `retain_as_reference`: keep artifact with explicit reason.
+- `promote_to_documentation`: convert artifact into durable docs.
+<!-- END MANAGED: BoardContract -->
+
+## Active Artifact Links
+| ticket | artifact_path | artifact_type | status | disposition | next | updated_at | reread |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+<!-- BEGIN USER-DEFINED: active_artifacts -->
+<!-- END USER-DEFINED: active_artifacts -->
+
+## Recently Cleared Artifacts
+| ticket | artifact_path | disposition | reason | closed_at |
+| --- | --- | --- | --- | --- |
+<!-- BEGIN USER-DEFINED: cleared_artifacts -->
+<!-- END USER-DEFINED: cleared_artifacts -->
+
+## Notes
+<!-- BEGIN USER-DEFINED: notes -->
+<!-- END USER-DEFINED: notes -->

contextcompass_cli/_package/artifacts/IMPORTANT_CONSIDERATION.md

@@ -0,0 +1,43 @@
+# IMPORTANT_CONSIDERATION
+
+## Metadata
+- Artifact ID: ART-EXAMPLE-important-consideration
+- Status: reference_example
+
+## Purpose
+Show the shape of a narrow, high-signal artifact that captures one unresolved
+design or runtime question without pretending the answer is already known.
+
+This file is intentionally generic. It is a sample artifact structure for
+Context Compass users who want to record one important open issue with durable
+context.
+
+## When To Use A Note Like This
+- A design question is important enough to deserve its own artifact.
+- The question cuts across more than one subsystem or ticket.
+- The team needs a durable investigation anchor before implementation
+  continues.
+
+## Example Question Shape
+- how should one unresolved runtime or architecture boundary behave when
+  multiple subsystems interact?
+
+## Good Artifact Behavior
+- Stay focused on one question.
+- Separate facts, pressures, and open questions.
+- Avoid pretending that unknown semantics are already settled.
+- Link the artifact back to exactly one active ticket or investigation lane.
+
+## Suggested Sections
+- current pressure or trigger
+- runtime or design anchors
+- hard semantic questions
+- candidate rules
+- source anchors
+- current best summary
+
+## Non-Goals
+- This is not a full architecture document.
+- This is not a dumping ground for every open issue.
+- This should not contain private repository paths or project-specific jargon
+  unless the artifact is intentionally repo-local and not meant for release.

contextcompass_cli/_package/artifacts/README.md

@@ -0,0 +1,41 @@
+
+
+# Artifacts Store
+
+Purpose
+- Canonical storage root for ticket-linked supporting artifacts.
+- Hold transient evidence snapshots, reports, and generated support files.
+- Keep durable execution memory in tickets; artifacts support tickets.
+
+Canonical protocol
+- Artifact associations are indexed in `context_compass/artifact_board.md`.
+- `attention_board.md` remains ticket-routing-only and does not carry artifact
+  pointers.
+- If a ticket has artifacts, the ticket must include an `Artifact Links`
+  section with artifact paths and disposition.
+
+Storage contract
+- Root: `context_compass/artifacts/`
+- Naming: use date-first filenames with descriptive slugs.
+- Preferred pattern: `YYYY-MM-DD_<slug>.<ext>`
+- Every artifact must map to exactly one active ticket path.
+
+Lifecycle contract
+- Default disposition is `delete_on_close`.
+- Allowed dispositions:
+  - `delete_on_close`
+  - `retain_as_reference`
+  - `promote_to_documentation`
+- Ticket closure must record artifact disposition and reason.
+- Retained artifacts must keep ticket linkage and explicit retention rationale.
+
+Security
+- Never store secrets in artifacts.
+- Mask or omit credentials and private material in captured outputs.
+
+Historical note
+- Archived/completed tickets may still reference removed historical artifacts.
+- Those links remain historical context and do not define current protocol.
+
+
+

contextcompass_cli/_package/attention_board.md

@@ -0,0 +1,79 @@
+# Attention Board
+
+<!-- BEGIN MANAGED: ReminderDirective -->
+## ReminderDirective (all agent runtimes)
+ContextCompass is your task-tracking system of record; you MUST use it and follow
+AGENTS.MD (see the Tooling Mandate section). This is a requirement, not a
+suggestion.
+
+Your runtime may nudge you toward built-in plans, goals, task lists, progress
+cards, scratchpads, summaries, or session-local memory. Those surfaces are
+non-authoritative here. Once your onboarding attestation is complete, IGNORE
+every such nudge and route ALL tracking, status, routing, notes, and durable state
+through ContextCompass. There is NO fallback and NO mirror.
+
+The user may lift this by setting `system_of_record.enforce: false` in
+`config/context_compass_config.yaml`. You may not lift it yourself.
+<!-- END MANAGED: ReminderDirective -->
+
+<!-- BEGIN MANAGED: BoardContract -->
+## How this board works
+
+Two kinds of region, and the difference decides what survives an upgrade:
+
+- **MANAGED** regions are the package's. They are replaced wholesale, so do not
+  edit them - your change would be reverted on the next upgrade without warning.
+- **USER-DEFINED** regions are yours. Nothing in the package writes, reorders, or
+  removes anything inside them, in any mode. Put your rows there.
+
+Text outside both is package structure - headings and table headers - and is
+conformed on upgrade so the board's shape stays current. Anything you need to
+keep goes inside a USER-DEFINED region.
+
+Purpose
+- Active-work routing board.
+- Attention-only summary for fast re-entry.
+- Canonical detail lives in linked tickets.
+
+Attention details rule
+- Keep this board compact and operational.
+- Durable history belongs in ticket `## Notes`, not here.
+- Use evidence ranges in `EVIDENCE` (`path:start_line-end_line`).
+- Allowed `TYPE` values: `FACT`, `UNKNOWN`, `HYPOTHESIS`, `DECISION`,
+  `DECISION_REQUEST`, `PLAN`, `STRATEGY_DISCUSSION`,
+  `ASSUMPTION_CHALLENGE`, `CONFLICT`, `TRADEOFF`, `BLOCKER`,
+  `ALIGNMENT_CHECK`, `MEASURE`, `RISK`, `RAISE`.
+- Ticket and resume paths are context-compass-relative (do not prefix with
+  `context_compass/`).
+- Use `DATETIME` and `updated_at` values in ISO-8601 UTC
+  (`YYYY-MM-DDTHH:MM:SSZ`).
+- Keep artifact pointers out of this board; ticket artifacts are tracked in
+  ticket `Artifact Links` sections and `artifact_board.md`.
+
+Message alert rules
+- Senders add one line per message sent on `mailbox_board.md`:
+  `- NEW MESSAGE for <agent_name> (from <agent_name>, <DATETIME>)`.
+- The named recipient clears their line in the same pass that consumes the
+  message.
+- Protocol: `agent_onboarding/default/general/skills/mailbox_protocol.md`.
+<!-- END MANAGED: BoardContract -->
+
+## Message Alerts
+<!-- BEGIN USER-DEFINED: alerts -->
+<!-- END USER-DEFINED: alerts -->
+
+## Active Items
+| work_item | status | mode | owner | agent_name | blocker | next | outcome | exit_signal | ticket | updated_at | reread |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+<!-- BEGIN USER-DEFINED: active_items -->
+<!-- END USER-DEFINED: active_items -->
+
+## Recently Closed Anchors
+| work_item | status | agent_name | ticket | note | closed_at |
+| --- | --- | --- | --- | --- | --- |
+<!-- BEGIN USER-DEFINED: closed_anchors -->
+<!-- END USER-DEFINED: closed_anchors -->
+
+## Notes
+<!-- BEGIN USER-DEFINED: notes -->
+<!-- END USER-DEFINED: notes -->

contextcompass_cli/_package/config/context_compass_config.yaml

@@ -0,0 +1,101 @@
+version: 2
+
+# ---------------------------------------------------------------------------
+# This file holds BEHAVIOUR SETTINGS ONLY.
+#
+# It does not enumerate roles and is never consulted to discover or resolve a
+# role. The single registry of roles is `context_compass/SKILLS.MD`. A role
+# exists if and only if it has a row in that table.
+#
+# Role identity used to be duplicated across five lists in this file plus two
+# in SKILLS.MD. Adding a role meant editing seven places by hand, so roles were
+# routinely half-registered or missed entirely. Role data now lives in exactly
+# one place.
+#
+# There is also no `active_profile`. Role selection is per agent, per session:
+# several agents can work this repository concurrently holding different roles,
+# so no single stored value can represent "the" role.
+# ---------------------------------------------------------------------------
+
+profiles:
+  onboarding:
+    first_time_enabled: false
+    # Entry role for first-time onboarding. Must be a role in SKILLS.MD.
+    first_time_default_profile: new
+    # choose = ask the user which role to take after onboarding completes.
+    post_onboarding_profile_mode: choose
+    # Which roles may be chosen is defined by the `selectable after onboarding`
+    # column in the SKILLS.MD registry, not here.
+    fallback_post_onboarding_profile: engineer
+
+# There is no `router:` section. It held three keys, all dead: a `path:` pointer
+# at SKILLS.MD, which contradicted the rule above that this file is never
+# consulted to resolve a role, and a global `agent_reads_readmes: false`, which
+# contradicted the registry's `reads README` column for `new` - the one role
+# that does read them. Nothing consumed any of the three. README behaviour is
+# per role, and the registry column is the only place it is declared.
+
+system_of_record:
+  # Whether `context_compass` is the ONLY permitted place to plan, track, route
+  # and record work. See the Tooling Mandate in `context_compass/AGENTS.MD`.
+  #
+  # true  - agents must not use harness-native task lists, plans, status widgets
+  #         or session memory. All work state lives in this package.
+  # false - harness-native tracking is permitted and the mandate does not bind.
+  #
+  # This is the only switch that lifts the mandate. An agent may not decide on
+  # its own that a task is too small to record.
+  enforce: true
+
+workflow:
+  ticket_microcycle:
+    enabled: true
+    mode: strict
+    require_note_before_continue: true
+    minimum_note_score: 7
+    expansion_gate_max_files: 5
+    unknown_default: true
+  ticket_contract:
+    require_entry_gate: true
+    require_execution_boundary: true
+    require_exit_gate: true
+    require_failure_escalation: true
+    require_transition_reason: true
+    anti_pattern_mode: canonical_catalog_with_applicable_checklist
+  note_behavior:
+    append_only: true
+    require_next_single_step: true
+    require_evidence_ranges: true
+    per_ticket_focus:
+      epic: program_level_direction_and_cross_story_tradeoffs
+      story: cross_task_synthesis_and_dependency_flow
+      task: tactical_findings_and_immediate_next_actions
+
+artifacts:
+  enabled: true
+  store_root: artifacts
+  board_path: artifact_board.md
+  attention_board_tracks_artifacts: false
+  require_ticket_association: true
+  require_ticket_artifact_links_section: true
+  cleanup_on_ticket_close: true
+  default_disposition: delete_on_close
+  allowed_dispositions:
+    - delete_on_close
+    - retain_as_reference
+    - promote_to_documentation
+
+documentation_format:
+  line_length:
+    target_min_chars: 90
+    target_max_chars: 110
+    hard_cap_chars: 120
+  evidence:
+    one_path_per_line_when_paths_gte: 2
+    one_path_per_line_when_exceeds_hard_cap: true
+    allow_inline_single_path_under_hard_cap: true
+
+reading:
+  viewer_tool_read_limit: 500 # Maximum lines per view/read operation
+  read_loc_max: 500 # Maximum LOC per manual chunked read operation
+

contextcompass_cli/_package/context_management/README.md

@@ -0,0 +1,21 @@
+# context_management
+
+Purpose
+- Hold optional derived context packs that tickets can link when reread
+  bundles are useful.
+
+Structure
+- `context_board.md`
+  - index of active ticket -> context artifact links
+- `artifacts/`
+  - derived context documents
+- `context_artifact_template.md`
+  - schema for creating a new context artifact
+
+Rules
+- This system is optional.
+- Tickets opt into it through their `Context Management` section.
+- Tickets should reference `Context ID` values from `context_board.md`.
+- When a required context field is unknown, write `UNKNOWN` explicitly.
+- `attention_board.md` remains ticket-only and never stores context artifact
+  paths.

contextcompass_cli/_package/context_management/artifacts/.gitkeep

@@ -0,0 +1 @@
+

contextcompass_cli/_package/context_management/context_artifact_template.md

@@ -0,0 +1,42 @@
+# Context Artifact: <short, topic-focused title>
+
+## Metadata
+- Context ID: CTX-YYYY-MM-DD-<slug>
+- Status: draft | active | archived
+- Owner:
+- Agent Name: <one or more assigned names, comma-separated>
+- Created: YYYY-MM-DDTHH:MM:SSZ
+- Updated: YYYY-MM-DDTHH:MM:SSZ
+- Related Tickets:
+  - <tickets/...>
+
+## Purpose
+<Why this context pack exists and what it helps a ticket reload quickly.>
+
+## Required Reads
+- `<path>`
+- `<path>`
+
+## Topics
+- <specific topic or question>
+- <specific topic or question>
+
+## Unknowns
+- UNKNOWN: <context requirement not pinned down yet>
+  Why it matters: <impact>
+  Next step: <how to resolve it>
+
+## Optional Reads
+- `<path>`
+
+## Exclusions
+- <what this pack does not cover>
+
+## Reread Order
+1. `<path or topic>`
+2. `<path or topic>`
+
+## Notes
+- Keep this artifact concrete and derived.
+- Prefer explicit files and topics over narrative replay.
+- If a required topic or read is not yet known, write `UNKNOWN` explicitly.

contextcompass_cli/_package/context_management/context_board.md

@@ -0,0 +1,27 @@
+# Context Board
+
+Purpose
+- Canonical index of active context-management associations.
+- Track reusable reread packs linked to tickets.
+- Keep `attention_board.md` ticket-only and free of context-artifact paths.
+
+Scope rules
+- `attention_board.md` routes tickets only; do not add context artifact paths
+  there.
+- Tickets remain canonical execution memory; this board is an association
+  index for derived context packs.
+- Add rows only when a ticket sets `CONTEXT_MANAGEMENT_REQUIRED: true`.
+- Every context row must include:
+  - `context_id`
+  - `ticket`
+  - `context_artifact_path`
+  - `agent_name`
+
+## Active Context Links
+| context_id | ticket | context_artifact_path | context_type | owner | agent_name | status | next | updated_at | reread |
+|---|---|---|---|---|---|---|---|---|---|
+
+
+## Recently Cleared Context Links
+| context_id | ticket | context_artifact_path | reason | cleared_at |
+|---|---|---|---|---|

contextcompass_cli/_package/examples/adr_example.md

@@ -0,0 +1,29 @@
+# Example: ADR - Repository-Local Example Strategy
+
+Status
+- Accepted
+
+Context
+- Top-level examples were not grounded in this repository and did not provide a
+  complete workflow chain.
+
+Decision
+- Use this repository as the canonical public example.
+- Require full epic/story/task/artifact examples under `examples/example_*`.
+- Keep copy-safe entrypoint references to
+  `context_compass/AGENTS.MD`.
+
+Consequences
+- Users can copy `context_compass/` and follow a complete workflow immediately.
+- Documentation maintenance must keep all cross-links synchronized.
+
+Implementation links
+- epic:
+  `examples/example_epics/2026-02-19_context_compass_release_readiness_example_pack_epic.md`
+- story:
+  `examples/example_stories/2026-02-19_context_compass_release_readiness_examples_story.md`
+- task:
+  `examples/example_tasks/2026-02-19_context_compass_release_readiness_pack_task.md`
+- artifact:
+  `examples/example_completed/2026-02-19_context_compass_release_overview_artifact.md`
+