> For the complete documentation index, see [llms.txt](https://faction-os.gitbook.io/faction-os-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/sessions/phase08-session07-legacy-evidence-decommission-and-media-release-gate/spec.md). # Session Specification **Session ID**: `phase08-session07-legacy-evidence-decommission-and-media-release-gate` **Phase**: 08 - Release Hardening and Legacy Decommission **Status**: Complete **Created**: 2026-05-31 **Completed**: 2026-05-31 **Package**: Cross-cutting **Package Stack**: Node 20 scripts and gates, TypeScript/Vitest media validation, stable documentation, public-demo cache review, release evidence, and Phase 08 PRD artifacts across `.spec_system/PRD/phase_08`, `docs`, `scripts`, `tests`, `public-demo`, `apps/web`, and legacy `EXAMPLES` evidence paths *** ## 1. Session Overview This session closes the Phase 08 legacy evidence and media release gate before final release-candidate validation. Sessions 01 through 06 created the release baseline, erasure inventory, local/browser erasure controls, Worker room-state and hosted identity gates, production-hosted smoke evidence, and mobile and accessibility evidence. The next unresolved blocker is that legacy evidence under `EXAMPLES`, historical reports, ignored media intake, copied bundles, and `docs/PROGRESS.md` is still candidate-only: no deletion, reduction, archive, or retention decision is approved until this session records the final action matrix and proves affected gates still pass. The work preserves useful requirements, contracts, risks, provenance conclusions, hashes, future-work notes, and historical rationale in stable docs before any cleanup action. It also revalidates media release readiness, quarantine boundaries, public-demo cache expectations, sensitive-output rules, and no-overclaim release wording. Cleanup is allowed only where the approval record names the exact candidate, stable replacement, disposition, gate evidence, owner, and rollback or recovery note. This is not a broad refactor or media promotion session. It should keep release-ready media limited to approved battlefield runtime records unless source, rights, attribution, metadata, fallback, accessibility, privacy, and budget evidence closes a specific blocker. It must not copy raw prompts, tokens, OAuth values, probe output, command output, sensitive local paths, copied historical code, generated provider payloads, or quarantined media content into stable docs. *** ## 2. Objectives 1. Finalize the Session 07 decommission approval/action record for historical findings, reports, ignored media intake, copied bundles, generated drafts, sensitive evidence, archived specs, and `docs/PROGRESS.md`. 2. Preserve retained requirements, contracts, risks, provenance conclusions, hashes, future-work notes, and historical rationale in stable docs before any deletion, reduction, archive, or explicit retention decision. 3. Execute only approved cleanup or retention changes, with exact candidate paths, disposition rationale, stable replacement references, gate evidence, and rollback notes. 4. Revalidate media, provenance, quarantine, public-demo cache, sensitive-output, docs, whitespace, ASCII, and LF gates after cleanup and update release docs for Session 08 handoff. *** ## 3. Prerequisites ### Required Sessions * [x] `phase08-session01-release-requirements-and-risk-baseline` - provides release claim gates, routing, risk ownership, and the initial candidate-only decommission matrix. * [x] `phase08-session02-unified-erasure-contract-and-inventory` - provides erasure vocabulary and no-overclaim boundaries that cleanup docs must preserve. * [x] `phase08-session03-local-erasure-runtime-and-controls` - provides local/browser deletion evidence that must not be confused with legacy evidence decommission. * [x] `phase08-session04-war-room-and-hosted-identity-release-gate` - provides Worker room-state erasure and hosted identity no-claim boundaries that release docs must preserve. * [x] `phase08-session05-production-hosted-validation-and-deploy-smoke` - provides production-hosted smoke evidence and sanitized-output rules that media/decommission gates must not weaken. * [x] `phase08-session06-mobile-and-accessibility-certification-evidence` - provides certification evidence boundaries that release docs must keep separate from media and decommission work. ### Required Tools/Knowledge * Phase 08 decommission matrix: `.spec_system/PRD/phase_08/decommission_approval_matrix.md`. * Phase 08 routing and risk artifacts: `.spec_system/PRD/phase_08/phase08_requirement_routing_matrix.md` and `.spec_system/PRD/phase_08/phase08_release_risk_matrix.md`. * Release, legacy, media, privacy, hosted-service, environment, public-demo, and package docs under `docs`, `public-demo/docs_public-demo`, and package README files. * Current media gates: `npm run media:gates:check`, `npm run media:check`, `npm run media:visual:check`, `npm run media:demo:check`, `npm run media:drafts:check`, and `npm run battlefield:check`. * Secret, sensitive-output, whitespace, ASCII, LF, and docs review patterns from `scripts/scan-secrets.mjs`, `scripts/check-media-release-gates.mjs`, and existing tests. ### Environment Requirements * Node 20+ and npm workspaces installed. * Local repository has the relevant legacy evidence paths available, or the approval record marks unavailable paths explicitly. * No hosted auth, hosted storage, analytics, push, remote access, Cloudflare Tunnel, media-provider credentials, or real executors required. * If cleanup touches ignored local evidence, the implementation records paths and outcomes without committing raw ignored content. *** ## 4. Scope ### In Scope (MVP) * Maintainer can read a Session 07 final approval/action record that maps each candidate to retain, archive, reduce, delete, or blocked, with stable replacement references and gate evidence. * Stable docs preserve unique requirements, contracts, risks, media provenance conclusions, hashes, future-work notes, and rejected/deferred rationale before cleanup. * Historical findings, copied first-pass artifacts, reports, `docs/PROGRESS.md`, ignored media intake, generated drafts, sensitive service-discovery evidence, and archived specs each receive explicit disposition coverage. * Approved cleanup or retention changes are applied only after the matrix records the candidate, owner, rationale, stable docs, and rollback or recovery note. * Media release gates, provenance checks, quarantine checks, public-demo service-worker cache review, sensitive-output scan, docs review, whitespace, ASCII, and LF validation are run or blockers are recorded with exact commands. * Release, legacy-consolidation, media, privacy/security, hosted-services, environments, public-demo, and relevant README docs reflect final retained or removed evidence without overclaiming media readiness, certification, hosted identity, production-hosted validation, or trusted erasure. ### Out of Scope (Deferred) * Promoting quarantined historical media to runtime, public-demo, release, or marketing use - *Reason: no media can become release-ready without full source, rights, attribution, metadata, fallback, accessibility, privacy, and budget evidence.* * Copying raw prompts, token values, OAuth ids, probe outputs, command bodies, terminal output, sensitive local paths, copied historical code, generated provider payloads, or quarantined media excerpts into stable docs - *Reason: stable docs preserve conclusions, not sensitive raw evidence.* * Deleting archived spec-system session or phase validation records - *Reason: archived validation history remains retained unless a separate archival policy replaces it.* * Adding hosted auth, hosted storage, analytics capture, public replay hosting, push delivery, remote access, Cloudflare Tunnel, hosted diagnostics, provider generation, or real executors - *Reason: this session owns cleanup and gate evidence only.* * Running final full release-candidate closeout - *Reason: Session 08 owns the final release gate stack and PRD/security/docs synchronization.* *** ## 5. Technical Approach ### Architecture Use the Phase 08 decommission matrix as the authority for decisions. The implementation should create a Session 07 successor artifact under `.spec_system/PRD/phase_08/` that records final dispositions, affected paths, stable replacement docs, gate commands, command outcomes, residual blockers, and rollback or recovery notes. The existing `decommission_approval_matrix.md` should be updated from candidate-only baseline to final Session 07 status, but the detailed command evidence can live in the new artifact to keep the matrix readable. Treat cleanup as a guarded write path. Before any file or directory is deleted, reduced, archived, or explicitly retained, confirm that stable docs preserve the retained value and that raw sensitive or quarantined material is not copied into tracked output. If a candidate lacks a stable replacement, mark it blocked or retained with rationale. If an ignored local path is unavailable in the working tree, record that as unavailable evidence instead of inventing content. Re-use existing gates instead of adding broad new infrastructure. The media release gate already reconciles catalog records, visual promotion config, public-demo media config, draft manifest, docs, browser evidence, lazy media policy, and sensitive-output checks. Pair those gates with docs review, secret scan, whitespace, ASCII/LF checks, and focused tests only where cleanup changes tracked code or scripts. ### Design Patterns * Matrix-driven cleanup: every action starts from a candidate row, stable replacement, owner, disposition, and gate result. * Preserve-before-remove: stable docs or explicit retained records must exist before deletion, reduction, or archive. * Sensitive-output minimization: tracked evidence records labels, counts, statuses, hashes, booleans, docs paths, and sanitized conclusions only. * Fail-closed disposition: missing replacement docs, unresolved media blockers, or unavailable evidence produce retain/blocked outcomes rather than deletion. * Local-first no-overclaim wording: cleanup must not imply hosted identity, trusted erasure, production-hosted validation, formal certification, or broad media readiness. ### Technology Stack * Markdown Phase 08 PRD artifacts and stable docs. * Node 20 npm workspace commands for release and media gates. * Existing media release scripts under `scripts/`. * Vitest for focused gate tests if tracked script or validation helper code changes. * Public-demo service-worker cache file and static media config review. *** ## 6. Deliverables ### Files to Create | File | Purpose | Est. Lines | | --------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | | `.spec_system/PRD/phase_08/legacy_decommission_media_release_gate.md` | Final Session 07 approval/action record, disposition matrix, stable-doc replacement map, gate command record, cleanup notes, residual blockers, and Session 08 handoff | \~180 | ### Files to Modify | File | Changes | Est. Lines | | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | ---------- | | `.spec_system/PRD/phase_08/decommission_approval_matrix.md` | Update candidate-only baseline with final Session 07 disposition status and pointer to action record | \~80 | | `.spec_system/PRD/phase_08/phase08_requirement_routing_matrix.md` | Mark S0807 evidence as produced and keep S0808 as final release closeout owner | \~25 | | `.spec_system/PRD/phase_08/phase08_release_risk_matrix.md` | Update P08-RISK-009, P08-RISK-010, and P08-RISK-011 residual wording based on gate outcomes | \~40 | | `docs/release.md` | Add final decommission/media gate commands, outcomes, remaining blockers, and no-overclaim release wording | \~90 | | `docs/legacy-consolidation.md` | Preserve retained historical value, final dispositions, blocked candidates, and replacement docs without raw sensitive content | \~120 | | `docs/media-assets.md` | Update media release gate status, conditional blocker posture, public-demo cache notes, and retained media provenance conclusions | \~80 | | `docs/privacy-and-security.md` | Update sensitive-output and legacy evidence posture if cleanup changes retained privacy/security notes | \~50 | | `docs/hosted-services.md` | Keep hosted no-claim wording aligned if historical hosted-service evidence is reduced or retained | \~40 | | `docs/environments.md` | Keep reserved credential and sensitive-output guidance aligned with final cleanup results | \~35 | | `public-demo/docs_public-demo/validation.md` | Record public-demo media/cache validation expectations after decommission and media gate review | \~50 | | `README.md` | Update top-level release/decommission status if retained or removed evidence affects project-facing guidance | \~35 | | `apps/web/README_web.md` | Preserve media and evidence boundaries for web runtime assets if media docs change | \~35 | | `public-demo/sw.js` | Bump or confirm cache version only if public-demo precache content changes | \~10 | | `EXAMPLES/findings/` | Apply approved retain, reduce, archive, or delete decisions for historical findings if stable replacements and gates allow | variable | | `EXAMPLES/1st-pass-artifacts/` | Apply approved retain, reduce, archive, or delete decisions for copied historical bundles if stable replacements and gates allow | variable | | `EXAMPLES/REPORT.md` and `EXAMPLES/REPORT.html` | Apply approved report retain, archive, or delete decisions if unique findings are preserved | variable | | `docs/PROGRESS.md` | Retain, reduce, archive, or delete only after current phase history and stable docs preserve needed milestones | variable | *** ## 7. Success Criteria ### Functional Requirements * [ ] Every candidate in the decommission matrix has a final Session 07 disposition, stable replacement reference, owner, gate status, and rollback or recovery note. * [ ] No legacy evidence is deleted or reduced unless the approval record proves retained value is preserved in stable docs or explicit retained records. * [ ] Quarantined media, generated drafts, conditional public-demo audio/music, portraits, brand/showcase media, and unknown-provenance records remain non-release unless all promotion blockers are closed. * [ ] Stable docs preserve conclusions without copying raw prompts, tokens, OAuth ids, probe outputs, command bodies, local paths, copied code, generated provider payloads, or quarantined media excerpts. * [ ] Release docs and Phase 08 artifacts distinguish cleanup evidence from trusted erasure, hosted identity, production-hosted validation, formal certification, and final release-candidate closeout. ### Testing Requirements * [ ] Media gate commands pass or blockers are recorded with exact command output summaries. * [ ] Secret scan, sensitive-output review, whitespace, ASCII, LF, and `git diff --check` pass after cleanup. * [ ] Focused tests are run for any changed scripts, gate helpers, media config, public-demo cache logic, or package code. * [ ] Manual review records unavailable ignored paths, blocked disposition rows, and any retained residual risks. ### Non-Functional Requirements * [ ] Local-first workflows remain unaffected by cleanup and do not require hosted, analytics, Cloudflare, provider, push, remote, or executor credentials. * [ ] Tracked evidence is sanitized and uses labels, statuses, counts, docs paths, hashes, booleans, and concise conclusions only. * [ ] Public-demo cache behavior remains deterministic if any precached content changes. * [ ] Documentation remains concise enough to be useful as stable release guidance rather than duplicating historical reports. ### Quality Gates * [ ] All files ASCII-encoded. * [ ] Unix LF line endings. * [ ] Code and docs follow project conventions. * [ ] `npm run media:gates:check` passes or exact blockers are recorded. * [ ] `npm run security:secrets` passes. * [ ] `git diff --check` passes. *** ## 8. Implementation Notes ### Key Considerations * Session 01 explicitly approved no deletion. Session 07 is the first session allowed to record final dispositions, and it must still block cleanup when stable replacements or gates are incomplete. * Archived spec-system session records and phase artifacts are retained unless a separate archival policy replaces validation evidence. * If ignored `EXAMPLES` paths are not present locally, record their unavailable status and preserve candidate/no-claim wording rather than inventing a disposition from absent evidence. * Media release-ready status remains limited to approved battlefield runtime records unless all blocker evidence changes. * `docs/PROGRESS.md` can be reduced or retained only if current PRD phase history, stable docs, archived summaries, and Git history preserve the needed milestones. ### Potential Challenges * Legacy evidence can contain sensitive raw content: mitigate by preserving only conclusions, paths, hashes, counts, and status labels in tracked docs. * Cleanup can remove the only source for a historical rationale: mitigate by requiring stable-doc replacement references before each disposition changes from candidate/retain to reduce/archive/delete. * Media gates may expose pre-existing blockers: mitigate by recording exact blocker scope and keeping conditional media non-release rather than broadening the session. * Ignored local media or reports may vary by workstation: mitigate by recording unavailable or local-only evidence without committing ignored content. ### Relevant Considerations * \[P07] **Redaction is boundary-specific**: decommission evidence must not expose raw env values, tokens, ids, paths, payloads, prompts, logs, backups, replay buffers, or quarantined content. * \[P04] **Asset provenance gate remains active**: only battlefield runtime records are release-ready; conditional and historical media retain blockers until full promotion evidence exists. * \[P03] **Stable docs are the current contract**: current README files, API docs, architecture, privacy, deployment, release, and legacy-consolidation docs must preserve retained value before historical cleanup. * \[P07] **Phase complete is not release complete**: Session 07 can close media/decommission evidence, but Session 08 still owns final release-candidate validation and docs/security synchronization. * \[P01] **Credentials are not consent**: environment variables, hosted config, media-provider credentials, or historical service evidence must not be interpreted as active capability or transfer consent. ### Behavioral Quality Focus Checklist active: Yes Top behavioral risks for this session: * Cleanup actions can be irreversible if they run before stable-doc replacement and rollback notes exist. * Evidence records can accidentally expose sensitive historical values while trying to preserve context. * Media/cache changes can create release overclaims or stale public-demo offline behavior if gates are not rerun after cleanup. *** ## 9. Testing Strategy ### Unit Tests * Run focused Vitest tests only if tracked scripts, media config, public-demo cache logic, or package code changes. * If validation helper code is added, test unsafe path handling, blocked disposition handling, sensitive-output rejection, unavailable ignored paths, and deterministic issue ordering. ### Integration Tests * Run `npm run media:gates:check` to reconcile catalog records, visual promotion config, public-demo media config, draft manifest, docs, browser evidence, lazy media policy, cache policy, and sensitive-output checks. * Run `npm run media:check`, `npm run media:visual:check`, `npm run media:demo:check`, `npm run media:drafts:check`, and `npm run battlefield:check` for affected media/provenance/cache coverage. * Run `npm run security:secrets` after tracked cleanup and documentation updates. ### Manual Testing * Review every decommission candidate against stable replacement docs before marking retain, archive, reduce, delete, or blocked. * Review docs for no-overclaim wording around media readiness, trusted erasure, hosted identity, production-hosted validation, formal certification, analytics, push, public replay, remote access, and real executors. * If ignored `EXAMPLES` media or generated drafts are present locally, verify no runtime/public-demo path imports or caches them before recording disposition. ### Edge Cases * Candidate path is absent locally: record unavailable evidence and keep conservative disposition. * Candidate contains unique requirement or risk not present in stable docs: retain or block cleanup until a concise stable replacement exists. * Stable replacement would require raw sensitive content: preserve conclusion only or retain source privately; do not copy raw value. * Public-demo precache content changes: update or confirm `CACHE_VERSION` and rerun public-demo/media gates. * Gate failure is pre-existing and outside Session 07 scope: record exact blocker, affected claim, and handoff to Session 08 without deleting additional evidence. *** ## 10. Dependencies ### External Libraries * None expected. Use existing Node 20, npm workspace, Biome, Vitest, Playwright, media gate, and secret scan tooling. ### Other Sessions * **Depends on**: `phase08-session01-release-requirements-and-risk-baseline`, `phase08-session02-unified-erasure-contract-and-inventory`, `phase08-session03-local-erasure-runtime-and-controls`, `phase08-session04-war-room-and-hosted-identity-release-gate`, `phase08-session05-production-hosted-validation-and-deploy-smoke`, `phase08-session06-mobile-and-accessibility-certification-evidence` * **Depended by**: `phase08-session08-release-candidate-validation-and-documentation-closeout` *** ## Next Steps Run the implement workflow step to begin AI-led implementation. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/sessions/phase08-session07-legacy-evidence-decommission-and-media-release-gate/spec.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.