governing-legacy-retention-and-archives

Preserve the original content unmodified, add archive metadata with content hash, superseded_by path, and rollback reference, then record it in a manifest with active_authority set to false. Update active references to point at the current canonical document instead of blanking the old file.

Lifecycle state describes the processing stage, such as CURRENT, MERGE_TO_CANONICAL, or DELETE_CANDIDATE. Retention classification describes the preservation duty, such as ARCHIVE_HISTORY, EVIDENCE_RETENTION, or DELETE_PROHIBITED_SECRET. The two must be recorded separately, never merged into one field.

No. Secrets, tokens, credentials, and private keys are classified DELETE_PROHIBITED_SECRET and must never be archived. They go through revoke, rotate, and remove procedures, and incident records must not copy the secret's original text.

Only after the deletion gate passes: unique content is preserved in canon or archive, active references are updated or stubbed, hashes and manifests are verified, a reproducible rollback ref exists, and deletion approval is documented. Branches additionally require a unique-commit audit and optional archive tag.

Mark it COMPATIBILITY_ONLY with load_by_default false and routable false, set a replaced_by pointer to the active skill, and update the registry, aliases, tests, and documentation references in the same change. Physical moves without these coupled updates are treated as failures.

Classify it as KEEP_UNRESOLVED and make no changes. Never judge retention by filename or date alone; investigate content, hashes, active references, and unique information until the classification is defensible.