A

Decisions

Decision pages record architectural choices that future work must respect or explicitly supersede. The topic graph defines decisions as this repository's neighborhood for choices that shape structure, workflows, and product surface [@topics].

Read these pages before adding compatibility paths, lifecycle orchestration, model selection behavior, page format changes, or root-selection behavior.

Product Boundary#

Local-only Python product is the base product decision: CodeAlmanac is a local Python tool with repo-owned Markdown source and machine-local runtime state [@local-only].

Only Almanac root narrows that shape to one wiki source root: almanac/. It rejects .almanac/, docs/almanac/, custom roots, and root migration shims as current product surfaces [@root].

Wiki Format#

Markdown links and sources decides that page navigation uses normal Markdown links and evidence uses structured sources: entries with inline citations [@links-sources].

No page-kind field decides that page type stays expressed through folder placement and topics rather than a validated kind frontmatter field, until a concrete behavior needs it [@page-kind].

Lifecycle Execution#

No propose/apply or dry-run rejects lifecycle proposal files, apply steps, dry-run rehearsals, and state machines between writer and reviewer [@no-propose].

Auto-commit is prompt policy decides that auto-commit changes the instructions given to lifecycle agents; CodeAlmanac does not stage, split, or commit wiki diffs itself [@auto-commit].

Harness Models#

Controlled model catalog decides that supported runner models are owned by CodeAlmanac config and tests, not by provider discovery or provider defaults [@model-catalog].

Telemetry permission is final setup step records the setup contract for the narrow telemetry exception: telemetry permission comes after runner, model, instruction, maintenance, update, and change-handling choices, with an explicit telemetry.enabled config setting [@telemetry-setup].

Repository Scope#

Repository affiliation belongs in repository service is a proposed decision, not yet implemented. It records the intended ownership boundary for mapping a transcript's working directory back to a canonical registered repository, so that future worktree or nested-checkout support lands as a repository-service method instead of Conductor-specific sync logic [@repo-affiliation].