atm10-source-of-truth-check

# atm10-source-of-truth-check

## Intent
Use this skill to adapt `aoa-source-of-truth-check` to an `atm10-*` repository when the base workflow is right but the local public-doc and repo-surface map needs repo-relative detail.

## Trigger boundary
Use this skill when:
- the base `aoa-source-of-truth-check` workflow is already correct, but an `atm10-*` repo needs local canonical-file patterns, repo-relative docs, or doc review rules
- contributors need a thin overlay that maps repo-relative docs such as `README.md`, `docs/ARCHITECTURE.md`, or `docs/[canonical-guide].md`
- confusion exists between overview docs and authoritative files inside one local repo
- active commands, archived commands, public status, support-profile claims, runtime baseline notes, release posture, or local-only planning surfaces are being mixed
- a top-level ATM10 entrypoint is accumulating runbook-scale detail that should move to a canonical home
- a public-safe local route must distinguish tracked docs from ignored maintainer scratch, internal chronology, private logs, or tool-local config
- the family review doc and bundle-local checklist still need to stay aligned

Do not use this skill when:
- the main need is broader policy design rather than local document authority mapping
- the task is purely code-local and has no meaningful docs or guidance ambiguity
- the work would introduce new upstream technique meaning instead of thin local adaptation
- the main need is recording rationale for a decision rather than clarifying authority; use `aoa-adr-write`
- the authoritative files are already clear and the remaining work is an ordinary bounded change; use `atm10-change-protocol` or the base `aoa-change-protocol`
- the question belongs to ATM10 runtime behavior, perception truth, model-host selection, operator automation, or private local state rather than document authority

## Inputs
- repo-relative docs or guidance surfaces
- local canonical-file candidates
- local review rules for doc changes
- contributor confusion points
- ATM10 public-surface roles from `docs/SOURCE_OF_TRUTH.md`
- affected active, archived, generated/export, local-only, internal, or runtime-adjacent surfaces
- candidate validation path such as public-doc hardening tests, nested AGENTS checks, or a no-run review note
- base skill reference

## Outputs
- local source-of-truth map
- active/current versus archived, generated/export, local-only, internal, or runtime-adjacent placement map
- bounded clarification note
- repo-relative canonical-file pattern
- lightweight entrypoint guidance when a summary doc should route outward instead of duplicating commands or counters
- pointer to the family review surface
- verification summary for the local docs surface

## Procedure
1. start from `aoa-source-of-truth-check` instead of inventing a family-specific docs doctrine
2. read the ATM10 root route card and `docs/SOURCE_OF_TRUTH.md`; if a touched path has a nested `AGENTS.md`, read that before judging local authority
3. name the repo-relative docs, source/config/schema surfaces, generated/export companions, run artifacts, or local-only surfaces involved in the ambiguity
4. map each local concern to the smallest authoritative home, such as `MANIFEST.md` for public current state, `ROADMAP.md` for direction, `docs/RUNBOOK.md` for active runnable commands, `docs/ARCHIVED_TRACKS.md` for archived/recoverable command references, `docs/PRODUCT_EDGE_POSTURE.md` for support/test-tier claims, `docs/QWEN3_MODEL_STACK.md` for model/runtime baseline posture, or `docs/SOURCE_OF_TRUTH.md` for document-role rules
5. keep `README.md` and other entrypoints short and link-driven once the canonical home exists
6. separate tracked public docs from ignored local-only planning, internal chronology, private logs, host-specific paths, tokens, and tool-local config
7. keep the adaptation bounded to the local repo surface under review
8. make explicit what still depends on downstream human review, unpublished local policy, or ATM10-owned runtime evidence
9. verify that the clarification reduces ambiguity without making `aoa-skills` the authority for ATM10 behavior

## Contracts
- preserve the base skill meaning
- keep local file maps repo-relative and explicit
- surface local authority and review posture without hiding it
- keep the overlay public-safe and reviewable
- keep ATM10 source-of-truth claims inside ATM10-owned public docs and route cards
- keep active runbook content separate from archived or recoverable references
- keep generated, exported, installed, and run-artifact surfaces weaker than the authored files they summarize
- keep public support-profile claims no broader than the docs and test tiers that actually validate them
- keep private workstation paths, local model paths, private logs, hostnames, tokens, screenshots with sensitive details, and internal scratch out of public examples

## Risks and anti-patterns
- inventing a broader docs governance framework inside a thin overlay
- using family labels without reducing local ambiguity
- hiding local review rules in prose that looks canonical
- silently replacing the base skill with project doctrine
- treating `README.md`, generated outputs, run artifacts, or installed skills as the source of truth when ATM10 already has canonical docs
- mixing active commands with archived/recoverable references
- spreading release cadence, supported profiles, or test-tier claims across several docs when one canonical surface owns them
- turning ignored local-only planning or internal chronology into public truth
- using this overlay to make runtime, service, model, operator automation, or perception decisions that belong in ATM10-owned implementation and docs

## Verification
- confirm the base skill is still the right workflow
- confirm authoritative repo-relative files are named explicitly
- confirm local review posture is visible rather than implied
- confirm the adaptation reduces ambiguity without widening scope
- confirm active, archived, generated/export, local-only, internal, and runtime-adjacent surfaces are not collapsed into one role
- confirm entrypoint docs stay short and route to canonical homes where those exist
- confirm public-safe boundaries and private/local-only exclusions are preserved
- confirm any support-profile, release, or runtime-baseline wording points to the owning ATM10 surface
- confirm the family review doc and bundle-local checklist stay aligned

## Technique traceability
Manifest-backed techniques:
- AOA-T-0013 from `8Dionysus/aoa-techniques` at `cd276f040d55d490bd015b8698c7a5d594b9f875` using path `techniques/instruction/instruction-surface/single-source-rule-distribution/TECHNIQUE.md` and sections: Intent, When to use, Inputs, Outputs, Core procedure, Contracts, Risks, Validation
- AOA-T-0002 from `8Dionysus/aoa-techniques` at `cd276f040d55d490bd015b8698c7a5d594b9f875` using path `techniques/instruction/docs-boundary/source-of-truth-layout/TECHNIQUE.md` and sections: Intent, When to use, Inputs, Outputs, Core procedure, Contracts, Risks, Validation
- AOA-T-0009 from `8Dionysus/aoa-techniques` at `cd276f040d55d490bd015b8698c7a5d594b9f875` using path `techniques/instruction/docs-boundary/lightweight-status-snapshot/TECHNIQUE.md` and sections: Intent, When to use, Inputs, Outputs, Core procedure, Contracts, Risks, Validation

## Adaptation points
- local doc hierarchies
- repo-relative canonical-file patterns
- local review rules for doc changes
- repository-specific authority examples
- lightweight entrypoint rules for `README.md`, `MANIFEST.md`, and other summary docs
- active versus archived command placement
- public-safe exclusions for internal scratch, private logs, host-specific paths, and tool-local config
- family review doc and bundle-local review checklist