context-anchoring

# Context Anchoring ## Scope > Feature-level only — anchors decisions as a feature flows from design → implementation → bugfix → refactor. ## Config Resolution This skill manages a directory of per-feature context docs. Resolution order: 1. Read `.lattice/config.yaml` in the repo root. 2. If found and `paths.context_base` is set → use that directory as the context base (the Create behavior creates it on demand). 3. If there is no config file or no `paths.context_base` key → use the default `.lattice/context/`. Each feature gets one doc at `<context_base>/<feature-name>.md`. No default principles, no overlay modes, no override files -- just a thin template and per-feature docs that grow through enrichment. ## Why Context Anchors Exist AI has no persistent memory across sessions. Early decisions get contradicted, naming drifts, and the "why" evaporates -- a forgotten decision becomes a potential contradiction, a lost constraint becomes a violation, an unresolved question becomes a silent assumption. Context anchor docs prevent this by being: - **Feature-bound** -- one doc per feature, scoped decisions only - **Decision-focused** -- capture what, why, and what-else-was-considered for every choice - **Append-only** -- decisions are never removed or rewritten, only added chronologically - **Session-spanning** -- the doc outlives the conversation and carries context forward - **Git-native** -- lives in the repo, versioned alongside code Two documents per feature: the **r...