update-docs

# Update docs Run a documentation pass after the implementation and validation steps of a code-changing task. Update only artifacts affected by the change; an internal change with no contributor-, user-, or agent-visible impact needs no documentation edit. ## Check the knowledge base **Architecture or ownership changed?** Update `.github/memory/ARCHITECTURE.md` for component boundaries, process entry points, major abstractions, or build/data flow. **Files or responsibilities moved?** Update `.github/memory/FILE_MAP.md` when a significant path is added, removed, renamed, repurposed, or changes dependency direction. **The public-surface map changed?** Update `.github/memory/API_MAP.md` when a surface category, ownership boundary, authoritative registry, or extension-point location changes. Individual commands, options, properties, targets, diagnostics, templates, analyzers, or library members normally update their owning code/help/tests, not this non-exhaustive map, unless the map's summary becomes stale. **A repository-wide rule or pattern changed?** Update `.github/memory/CONVENTIONS.md`. Keep area-only guidance in the nearest `AGENTS.md` or skill and link to it from memory only when it is important for orientation. **Agent guidance changed?** Keep `.github/agents/*.agent.md` focused on role, boundaries, and orchestration. Link to repository memory, the nearest `AGENTS.md`, and owning skills instead of copying their maps, invariants, commands, or procedures. **Test strategy changed?** Update `.github/memory/TESTING_STRATEGY.md` for test platform architecture or canonical documentation ownership. Test selection, execution, and product-layout freshness belong in `run-tests`; authoring and Helix-safe test conventions belong in `test/AGENTS.md`; conditional-filtering details belong in `test/ConditionalTests.props` and its design documentation. **A durable gotcha or workaround was found or removed?** Update `.github/memory/KNOWN_ISSUES.md`. Do not use it as a list of transient failures or open bugs. **Memory files changed?** Update `.github/memory/INDEX.md` when a file is added, removed, renamed, or changes purpose. Its loading map must list exactly the files that exist. ## Check other documentation Review the affected area for: - the root and nearest area `AGENTS.md` - `.github/skills/*/SKILL.md`, `.claude/skills/*/SKILL.md`, and `.github/agents/*.agent.md` - contributor and area guidance under `documentation/` - command help, usage text, completion and Verify snapshots ## Create a memory file only when warranted Create a focused memory file when the knowledge: - is durable enough to remain useful after the current task - is likely to be reused across tasks or repository areas - forms a coherent subject that does not fit an existing memory file - is scoped narrowly enough for `INDEX.md` to say when agents should load it without pulling unrelated context - can be grounded in stable primary sources Do not create a memory file for task status, investigation notes, transient failures, open-issue tracking, or a single implementation detail. Put area-specific rules in the nearest `AGENTS.md`, repeatable procedures in a skill, and contributor-facing guidance under `documentation/`. ## Ground and validate updates 1. Link important claims to the nearest primary repository source. 2. Cross-check memory against current code; do not copy a stale statement forward. 3. Mark inference or uncertainty instead of presenting it as established behavior. 4. Keep files focused and remove placeholders. 5. Give new memory files only `coverage:` frontmatter that states their precise scope, plus a descriptive filename. 6. Confirm every local Markdown link in each changed Markdown file resolves to an existing file and, when present, an existing heading anchor. When memory changes, validate all `.github/memory/*.md` files because their cross-references form one knowledge base.