> 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-session01-release-requirements-and-risk-baseline/spec.md). # Session Specification **Session ID**: `phase08-session01-release-requirements-and-risk-baseline` **Phase**: 08 - Release Hardening and Legacy Decommission **Status**: Complete **Created**: 2026-05-31 **Package**: Cross-cutting **Package Stack**: Markdown PRD/docs, release/security evidence, and source review across apps/server, apps/web, apps/warroom, apps/cli, apps/hooks, apps/adapters, public-demo, packages/protocol, and docs *** ## 1. Session Overview This session creates the Phase 08 release requirements and risk baseline before release hardening implementation begins. Phase 07 completed hosted-service and analytics guardrails, but the project still carries open release risks for trusted unified erasure, hosted identity claims, production-hosted validation, mobile/accessibility certification evidence, legacy decommission, media release gates, and final release-candidate closeout. The work is documentation-first and cross-cutting. It audits the Phase 07 closeout, PRD, UX PRD, considerations, security posture, release guide, deployment docs, hosted-service docs, privacy/security docs, architecture docs, environment docs, legacy-consolidation docs, Phase 08 stubs, and relevant stable package README/source boundaries. It then records ownership, evidence requirements, claim gates, risks, and decommission candidates so Sessions 02 through 08 can implement without overclaiming release readiness. The session must preserve FactionOS as local-first by default. Core local workflows must continue to work without hosted accounts, hosted storage, analytics, public replay hosting, push delivery, remote access, Cloudflare credentials, provider credentials, or real executors. Session 01 does not implement erasure, delete legacy evidence, validate production hosting, certify accessibility/mobile behavior, activate hosted identity, or approve media promotion. *** ## 2. Objectives 1. Create a source-backed Phase 08 release requirements and risk baseline that ties release, erasure, hosted identity, production validation, certification, media, and decommission work to current evidence. 2. Create a requirement-to-session routing matrix that assigns each Phase 08 release requirement to Sessions 02 through 08 or a clearly deferred later scope. 3. Define release claim gates for local-first mode, optional Worker federation, hosted identity, hosted storage, analytics, public replay, push, remote access, trusted erasure, certification, production-hosted validation, media release readiness, and legacy deletion. 4. Create initial release risk and decommission approval matrices that keep open findings visible and prevent accidental deletion or overclaiming before later sessions produce evidence. *** ## 3. Prerequisites ### Required Sessions * [x] `phase07-session07-hosted-guardrails-validation-and-documentation-closeout` - provides Phase 07 hosted-service guardrail validation, residual Phase 08 release risks, security posture, and documentation closeout. * [x] `phase07-session03-hosted-identity-and-authorization-guardrails` - provides planned-state hosted identity vocabulary, diagnostics boundaries, and Worker-authority non-overclaim wording. * [x] `phase07-session06-push-remote-access-and-operator-diagnostics-guardrails` - provides push, remote-access, tunnel, and operator diagnostic guardrails and unsupported-state wording. * [x] `phase06-session07-collaboration-isolation-and-mobile-validation-closeout` - provides scoped local browser mobile/accessibility evidence and the distinction from formal certification. * [x] `phase04-session08-media-validation-and-documentation-closeout` - provides media release gate, provenance, conditional media, and quarantine lessons. ### Required Tools/Knowledge * Node 20+, npm workspaces, Biome, Vitest, Playwright, TypeScript, React/Vite, Express, Cloudflare Workers, Durable Objects, Wrangler, and static public-demo deployment boundaries. * Current docs and spec sources: `.spec_system/PRD/PRD.md`, `.spec_system/PRD/PRD_UX.md`, `.spec_system/PRD/phase_08/PRD_phase_08.md`, Phase 08 session stubs, `.spec_system/CONSIDERATIONS.md`, `.spec_system/SECURITY-COMPLIANCE.md`, `docs/release.md`, `docs/deployment.md`, `docs/hosted-services.md`, `docs/privacy-and-security.md`, `docs/ARCHITECTURE.md`, `docs/environments.md`, and `docs/legacy-consolidation.md`. * Current package boundaries: `packages/protocol` owns shared contracts, `apps/server` owns loopback runtime and diagnostics, `apps/web` owns browser cockpit state and local UX, `apps/warroom` owns optional Worker room relay, `apps/cli` and `apps/hooks` own local lifecycle/diagnostics, `apps/adapters` owns outbound-only adapters, and `public-demo` owns standalone static demo behavior. ### Environment Requirements * Local checkout of the FactionOS monorepo with Phase 08 PRD and session stubs available. * Phase 07 archive artifacts and stable docs available for review. * No Supabase project, Umami site, Cloudflare credential, VAPID keypair, provider key, production app host, public replay host, tunnel token, or hosted account is required. * Tracked docs must not copy raw secrets, account ids, zone ids, OAuth values, provider keys, probe output, raw prompts, command output, sensitive local paths, or quarantined historical content. *** ## 4. Scope ### In Scope (MVP) * Maintainers can identify which session owns each Phase 08 release requirement - create requirement routing for erasure, hosted identity, production validation, mobile/accessibility evidence, media gates, decommission, docs, and final closeout. * Security reviewers can connect open findings to evidence and closeout criteria - map hosted identity, trusted erasure, production-hosted validation, media readiness, and decommission risks to owners and residual-risk wording. * Release readers can distinguish validated behavior from planned or unavailable claims - define claim gates for local-first operation, Worker federation, hosted services, analytics, push, remote access, trusted erasure, certification, and production hosting. * Maintainers can see decommission candidates without deletion approval - create an initial approval matrix for `EXAMPLES/`, findings, reports, ignored media intake, copied historical bundles, and `docs/PROGRESS.md`. * Stable documentation can use current Phase 08 ownership language - update PRD, UX PRD, release, deployment, hosted-service, privacy/security, architecture, environment, and legacy docs if stale ownership or no-overclaim language is found. ### Out of Scope (Deferred) * Implementing trusted erasure contracts, runtime deletion, CLI controls, web controls, Worker erasure, or audit execution - *Reason: Sessions 02 through 04 own erasure contract, local runtime, and Worker/identity release gates.* * Deleting, reducing, or archiving legacy evidence - *Reason: Session 07 owns approved decommission actions after the matrix is validated.* * Claiming production-hosted validation, hosted app readiness, deployed Worker release readiness, or Cloudflare dashboard readiness - *Reason: Session 05 owns production-hosted validation and deploy smoke evidence.* * Claiming formal WCAG certification, physical-device mobile certification, or broad accessibility certification - *Reason: Session 06 owns release evidence and no-overclaim documentation.* * Enabling hosted auth, hosted storage, analytics capture, public replay hosting, push delivery, remote access, tunnels, hosted diagnostics, or real executors - *Reason: Phase 08 release hardening must not expand active hosted surfaces without a separate scoped implementation and evidence.* * Promoting quarantined historical media or conditional public-demo media to release-ready status - *Reason: Session 07 owns media release gate revalidation and decommission decisions.* *** ## 5. Technical Approach ### Architecture This session uses documentation-as-contract. The created baseline artifacts become the source handoff for the remaining Phase 08 sessions, while stable docs keep current shipped behavior honest for users, maintainers, and release reviewers. Release hardening should stay additive, auditable, and reversible. Shared release vocabulary should start in spec and PRD artifacts before code changes. Secret-bearing, destructive, identity-sensitive, hosted, or certification-sensitive claims must require source, tests, docs, validation evidence, and residual-risk wording before release copy describes them as active or complete. The baseline must keep the local-first architecture explicit. Local server, web, hooks, CLI, adapters, public demo, and optional Worker room relay remain separate surfaces. Worker room authority is not hosted account identity, local cleanup is not trusted erasure, local/mocked browser evidence is not production-hosted validation, and automated checks are not formal accessibility certification unless matching evidence exists. ### Design Patterns * Requirement routing: every Phase 08 requirement names the smallest owning session or a later explicit deferral. * Evidence-gated claims: every release claim must map to source, tests, docs, validation evidence, and residual-risk wording. * Local-first no-overclaim wording: docs must distinguish shipped local behavior, optional Worker behavior, planned hosted surfaces, disabled states, unavailable states, and release blockers. * Decommission by approval matrix: legacy evidence remains retained unless stable docs preserve the unique value and the matrix records an approved disposition. * Boundary-specific redaction: release evidence must keep prompts, commands, paths, tokens, ids, room payloads, exports, replay buffers, logs, backups, media drafts, and historical intake out of tracked docs and diagnostics unless sanitized. ### Technology Stack * Markdown PRD, release baseline, routing matrix, release risk matrix, decommission matrix, docs, and README files. * Existing npm workspace packages: `packages/protocol`, `apps/server`, `apps/web`, `apps/warroom`, `apps/cli`, `apps/hooks`, and `apps/adapters`. * Existing release tools: `npm run format:check`, `npm run lint`, `npm run typecheck --workspaces --if-present`, `npm test`, `npm run build --workspaces --if-present`, media gates, battlefield check, secret scan, `git diff --check`, ASCII/LF scans, and docs review. *** ## 6. Deliverables ### Files to Create | File | Purpose | Est. Lines | | ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ---------- | | `.spec_system/PRD/phase_08/release_requirements_risk_baseline.md` | Source-backed Phase 08 release requirements, claim gates, evidence standards, and local-first release boundary | \~180 | | `.spec_system/PRD/phase_08/phase08_requirement_routing_matrix.md` | Requirement-to-session ownership matrix for Sessions 02-08 and explicit later deferrals | \~150 | | `.spec_system/PRD/phase_08/phase08_release_risk_matrix.md` | Open finding, release risk, evidence owner, closeout criteria, and residual-risk wording matrix | \~130 | | `.spec_system/PRD/phase_08/decommission_approval_matrix.md` | Initial legacy evidence, media, report, findings, and progress-ledger decommission approval matrix | \~120 | ### Files to Modify | File | Changes | Est. Lines | | ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | | `.spec_system/PRD/PRD.md` | Link Phase 08 baseline artifacts and clarify release-hardening ownership if stale | \~25 | | `.spec_system/PRD/PRD_UX.md` | Clarify Phase 08 certification, mobile/accessibility evidence, local erasure UX, hosted/no-overclaim UX, and release evidence language if stale | \~25 | | `.spec_system/PRD/phase_08/PRD_phase_08.md` | Link Session 01 outputs and align Sessions 02-08 with routing matrix ownership | \~30 | | `docs/release.md` | Add Phase 08 claim gates, risk ownership, and decommission approval matrix references | \~40 | | `docs/deployment.md` | Clarify production-hosted validation targets and no-claim unavailable states if stale | \~20 | | `docs/hosted-services.md` | Clarify hosted identity, storage, analytics, public replay, push, remote access, and erasure claim gates if stale | \~25 | | `docs/privacy-and-security.md` | Clarify open release findings, erasure coverage, evidence boundaries, and sensitive-output handling if stale | \~25 | | `docs/ARCHITECTURE.md` | Clarify release architecture boundaries and evidence-gated hosted/erasure claims if stale | \~20 | | `docs/environments.md` | Clarify validation environments, credential absence, and release no-claim behavior if stale | \~20 | | `docs/legacy-consolidation.md` | Add Phase 08 decommission matrix reference and candidate-only wording if stale | \~25 | *** ## 7. Success Criteria ### Functional Requirements * [ ] Phase 08 release requirements and risk baseline exists and cites current PRD, UX PRD, Phase 07 closeout, considerations, security posture, stable docs, and Phase 08 session stubs. * [ ] Routing matrix assigns release, erasure, hosted identity, production validation, mobile/accessibility evidence, media gate, decommission, documentation, and final closeout requirements to Sessions 02 through 08 or explicit later deferrals. * [ ] Release claim gates define required evidence for local-first mode, Worker federation, hosted identity, hosted storage, analytics, public replay, push, remote access, trusted erasure, certification, production-hosted validation, media readiness, and legacy deletion. * [ ] Release risk matrix maps open security and release findings to session owners, required evidence, closeout criteria, and residual-risk wording. * [ ] Decommission matrix lists candidates as candidates only and does not authorize deletion before stable docs preserve required value. * [ ] Stable docs do not overclaim hosted identity, production-hosted validation, trusted erasure, certification, media readiness, or decommission completion. ### Testing Requirements * [ ] Documentation path and link references reviewed for created and changed files. * [ ] Consistency scan completed for release claim gates, requirement ownership, risk wording, decommission candidate wording, local-first boundaries, and Phase 08 deferrals. * [ ] No app tests are required unless implementation changes source behavior; if code changes are needed, focused package tests are run. * [ ] ASCII/LF checks completed for all session outputs and touched docs. * [ ] `git diff --check` completed. ### Non-Functional Requirements * [ ] Core FactionOS workflows remain local-first and do not require hosted accounts, hosted storage, analytics, public replay hosting, push delivery, remote access, Cloudflare credentials, provider credentials, or real executors. * [ ] Release artifacts do not expose raw env values, tokens, account ids, zone ids, OAuth values, provider keys, room payloads, prompts, commands, local paths, exports, logs, backups, replay buffers, or quarantined historical content. * [ ] Local cleanup, browser reset, Worker leave, diagnostics recovery, and one-boundary deletion are not described as trusted unified erasure. * [ ] Local, mocked, or same-origin browser evidence is not described as production-hosted validation. * [ ] Automated accessibility/mobile checks are not described as formal certification unless matching manual or third-party evidence exists. ### Quality Gates * [ ] All files ASCII-encoded. * [ ] Unix LF line endings. * [ ] Code and docs follow project conventions. *** ## 8. Implementation Notes ### Key Considerations * Session 01 is a baseline and routing session. It should create evidence requirements and ownership, not implement release behavior. * The current security posture is at risk because hosted identity, trusted erasure, and production-hosted validation remain open release findings. * Phase 07 guardrails prove disabled, planned, unavailable, and local-only behavior only. They do not prove active hosted auth, storage, analytics capture, push delivery, public replay hosting, remote access, production deployment, trusted erasure, or certification. * Stable docs are the current contract. Archived PRDs, `EXAMPLES/`, old reports, and `docs/PROGRESS.md` are evidence only until decommission approval preserves their unique value. * The initial decommission matrix must not approve deletion by implication. Later Session 07 must finalize decisions and rerun affected gates before any deletion or reduction. * Release evidence must remain sanitized. Counts, labels, docs paths, booleans, hashes, and status summaries are safer than raw provider output, secrets, ids, payloads, prompts, commands, paths, logs, backups, exports, or replay buffers. ### Potential Challenges * Scope bleed into erasure implementation: record erasure requirements and claim gates here, but leave contracts and runtime behavior to Sessions 02 and 03. * Hosted identity overclaim: keep Worker room authority, browser Worker URLs, deployed Worker health, and account-backed identity separate. * Production validation ambiguity: Cloudflare Pages and Worker endpoints can be validation targets, but absent credentials or unavailable hosts must become no-claim evidence rather than assumed failures. * Decommission pressure: preserve unique requirements, contracts, risks, provenance conclusions, hashes, or future-work notes before any legacy evidence is deleted or reduced. * Certification wording: distinguish browser automation, manual device evidence, WCAG evidence, and formal certification. * Media gate drift: keep conditional media and quarantined historical media blocked until source, rights, attribution, optimization, metadata, fallback, accessibility, privacy, and budget evidence is recorded. ### Relevant Considerations * \[P07] **Unified erasure deferred to Phase 08**: one trusted erase/reset workflow must cover archives, memory, settings, lifecycle files, browser state, War Room Durable Object state, replay/export buffers, diagnostics, logs, backups, valid spool state, workspace files, and future hosted surfaces in release scope. * \[P07] **Hosted services ship as disabled-default guardrails only**: active hosted auth, storage, analytics, push, public replay, and remote access need scoped consent, minimization, redaction, authorization, abuse controls, tests, and docs before any active claim. * \[P07] **Phase complete is not release complete**: Phase 08 owns release hardening, trusted erasure, production-hosted validation, mobile certification, and legacy decommission. * \[P04] **Asset provenance gate remains active**: only approved battlefield runtime media are release-ready until promotion evidence closes blockers. * \[Security] **Open findings**: hosted identity, trusted erasure, and production-hosted validation remain active release risks. *** ## 9. Testing Strategy ### Unit Tests * No application unit tests are expected because this session produces planning and documentation artifacts only. * If implementation reveals a narrow source, config, or diagnostics fix, run the focused package test for that package before completing the task. ### Integration Tests * Run `git diff --check` for whitespace validation. * Run docs/path scans for changed references and created artifact links. * Run focused lint or formatting checks only if source or config files change. ### Manual Testing * Review created matrices for full coverage of Phase 08 session stubs and open security findings. * Verify stable docs distinguish shipped, planned, unavailable, evidence-only, and release-blocked behavior. * Confirm decommission candidates are not written as approvals. * Confirm release claim gates do not imply hosted identity, trusted erasure, certification, production-hosted validation, or media readiness before later sessions produce evidence. ### Edge Cases * Missing Cloudflare credentials, missing production app host, unavailable Worker endpoint, absent hosted account provider, absent Supabase storage, analytics disabled, push unavailable, remote access unavailable, tunnel absent, and provider credentials absent must produce no-claim or unavailable wording. * Partial erasure, idempotent erasure, dry-run mismatch, stale Worker authority, browser localStorage unavailable, backup retention edge cases, log cleanup failures, and replay/export remnants must remain routed to later erasure sessions. * Legacy evidence with unique requirements, contracts, risks, provenance conclusions, hashes, or future-work notes must be retained until stable docs preserve that value and Session 07 records approval. * Release docs must not preserve raw secrets, account ids, zone ids, OAuth values, probe output, prompts, commands, local paths, logs, backups, exports, replay buffers, room payloads, or quarantined historical excerpts. *** ## 10. Dependencies ### External Libraries * None expected for this documentation-first session. ### Other Sessions * **Depends on**: `phase07-session07-hosted-guardrails-validation-and-documentation-closeout`, `phase06-session07-collaboration-isolation-and-mobile-validation-closeout`, `phase04-session08-media-validation-and-documentation-closeout` * **Depended by**: `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`, `phase08-session07-legacy-evidence-decommission-and-media-release-gate`, `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-session01-release-requirements-and-risk-baseline/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.