docs: rebase canonical LifeOS product architecture on current main

CHANGELOG.md

@@ -4,12 +4,9 @@ All notable changes to LifeOS are documented in this file.
 
 ## Unreleased
 
-### Changed
-
-- Production contextual-orchestrator proposal requests now explicitly use adaptive `auto` mode and avoid provider-native structured-output passthrough, allowing the orchestration plane to meet the quality requirement and then minimize known cost while LifeOS retains strict fail-closed proposal validation.
-
 ### Added
 
+- A canonical architecture/governance decision for model-assisted test-time compute and repository development: ADR 0012 requires a strong single-route baseline, explicit stage/decomposition/recursion/role-effort/access-topology evidence, comparable-budget justification for deeper orchestration, `NVIDIA_NIM_API_KEY` through approved OpenCode/contextual-orchestrator boundaries, and strict separation of model execution from deterministic review, merge, and release authority. This documents and reconciles existing protected-main governance/live-conformance behavior rather than claiming a new shipped product capability.
 - Durable PostgreSQL plugin-installation authority with opaque UUIDv4 installation/workspace/installer identity, exact manifest digests, normalized explicit grants, bounded conflict replay, and atomic revocation evidence in the service-owned `plugin_integration` schema.
 - An authenticated calendar-connection disconnect application and optional hosted HTTP composition boundary that derives workspace and requesting-user authority only from the signed `life-os.calendar-user.v1` context and returns credential-free local revocation evidence.
 - A durable PostgreSQL data-rights request ledger with workspace-scoped idempotency, immutable request and terminal receipt digests, one-way completion state, and real integration evidence that erasure receipts survive removal of the source workspace and user.

CLAUDE.md

@@ -1,6 +1,6 @@
 # Claude operating contract for LifeOS
 
-`AGENTS.md` is the canonical repository-wide instruction file. This document maps that contract into a concise execution order for Claude-compatible agents and must not override `AGENTS.md`, `ARCHITECTURE.md`, branch protection, or security policy.
+`AGENTS.md` is the canonical repository-wide instruction file. `ARCHITECTURE.md` is the durable system-boundary source of truth. The canonical product documentation graph is indexed from `README.md` and includes PRD, TRD, ADRs, Data Model, UML, API contracts, threat/privacy/test/operability/release/standards/traceability views. This document maps those authorities into a concise execution order for Claude-compatible agents and must not override live repository policy.
 
 ## Execution order
 
@@ -10,9 +10,9 @@
 4. Make the smallest complete correction, including tests and documentation.
 5. Re-run the exact pull-request head and resolve only threads whose finding is actually addressed.
 6. Merge only when required checks pass, no actionable findings remain, and the repository's merge policy accepts the exact head.
-7. Continue with the highest-impact buyer-visible gap after the pull-request queue is empty.
+7. Continue with the highest-impact buyer-visible gap after the pull-request queue is empty or a current lane becomes locally blocked.
 
-Routine progress narration is not a substitute for repository evidence. Record decisions in code, tests, ADRs, specifications, plans, runbooks, issues, and pull-request descriptions.
+Routine progress narration is not a substitute for repository evidence. Record durable decisions in canonical docs/ADRs, code, tests, runbooks, issues, and pull-request evidence with truthful protected-main/active-PR/planned maturity.
 
 ## Non-negotiable boundaries
 
@@ -23,7 +23,9 @@ Routine progress narration is not a substitute for repository evidence. Record d
 - Internal identifiers are UUIDv4 strings; numeric external identifiers are mapped through an explicit provider-identity boundary.
 - Database objects use multiword `snake_case` names unless an external protocol mandates a different spelling.
 - Services do not read or mutate another service's database tables.
+- Browser-local state is not durable until accepted by the owning service.
 - AI proposals remain inert until a separately authorized user-confirmed execution capability exists.
+- Sensitive access is tenant/resource/purpose/lifetime/audit bound rather than relying on blanket masking.
 - Mathematical and psychometric numerical kernels require Rust, deterministic CPU/GPU execution boundaries, realistic parameter-recovery tests, multilevel or multiple-membership structure, and temporal modeling where applicable.
 
 ## LLM orchestration decisions
@@ -36,12 +38,13 @@ Live model tests may use `NVIDIA_NIM_API_KEY`. Deterministic pull-request checks
 
 - Production declarations have explanatory docstrings.
 - Changed production code maintains 100% statement, branch, function, and line coverage where the package enforces those gates.
-- Tests model realistic domain outcomes, not only mocked implementation calls.
+- Tests model realistic domain outcomes, including PostgreSQL/browser/concurrency/security behavior where applicable.
 - Standards and research claims are documented with APA 7 references and publication status is distinguished from drafts or preprints.
+- Canonical status fields use the exact repository vocabulary and never mix PR/issue qualifiers into the status value.
 - `CHANGELOG.md` records buyer-visible behavior.
-- `ARCHITECTURE.md` and relevant feature ADR/specification files record boundary changes.
+- PRD/TRD/Architecture/ADR/UML/Data Model/API/Security/Privacy/Test/Operability/Release/Traceability views are reconciled when their boundary changes.
 - Release tags and versions are created only after the repository proves release readiness; unreleased work stays under `Unreleased`.
 
 ## Safe escalation
 
-Escalate only for a decision or permission that cannot be resolved from repository policy, tests, standards, or available credentials. Waiting for checks or reviews is not itself an escalation condition; continue independent analysis, documentation, or the next non-conflicting planned task while preserving merge safety.
+Escalate only for a decision or permission that cannot be resolved from repository policy, tests, standards, or available credentials. Waiting for checks or reviews is not itself an escalation condition; continue independent analysis, documentation, testing, or the next non-conflicting planned task while preserving merge safety.

README.md

@@ -83,13 +83,13 @@ The calendar integration service supports explicit `caldav` and `google` provide
 
 CalDAV writes use deterministic resource names, `If-None-Match: *` for creation, and strong `If-Match` ETags for updates. Google Calendar writes use a deterministic API event identifier to prevent duplicate creation and the same strong-ETag precondition for updates. Neither adapter exposes delete, move, or copy operations through the LifeOS provider contract.
 
-`GOOGLE_CALENDAR_ACCESS_TOKEN` is an operator-supplied runtime secret for this bounded adapter slice. Per-user OAuth credential storage, token refresh, revocation, calendar discovery, and encrypted persistence remain deferred and must be implemented before a multi-user hosted deployment enables Google Calendar synchronization.
+The calendar service now derives workspace authority from a bounded signed server context rather than a client-selected legacy workspace header. `GOOGLE_CALENDAR_ACCESS_TOKEN` remains an operator-supplied development/runtime secret for the current provider slice. Per-user OAuth credential storage, token refresh, revocation, calendar discovery, selection, and encrypted persistence remain tracked by issue #129 before hosted multi-user Google Calendar operation can be considered complete.
 
 ## Plugin contract
 
 The `@life-os/plugin-sdk` package defines strict versioned manifests, tenant-scoped CloudEvents 1.0 structured JSON envelopes, deterministic canonical serialization, and HMAC-SHA256 delivery-proof helpers. The integration service exposes contract discovery, manifest validation, and event preparation only.
 
-This slice deliberately has no plugin installation, secret persistence, outbound webhook delivery, inbound commands, or direct database access. Those require separately reviewed least-privilege authorization, durable audit, and SSRF-safe delivery boundaries.
+This slice deliberately has no plugin installation, secret persistence, outbound webhook delivery, inbound commands, or direct database access. Those require separately reviewed least-privilege authorization, durable audit, and SSRF-safe delivery boundaries under issue #130.
 
 ## Backup and recovery
 
@@ -109,9 +109,32 @@ This is a public repository. It contains synthetic examples only. Personal goals
 
 The upstream project does not operate every LifeOS deployment. A self-hosting organization controls its deployment data and must establish its own privacy notice, retention policy, security controls, subprocessors, and legal basis. See the [upstream privacy notice](docs/legal/privacy.md) and [upstream project terms](docs/legal/terms.md) for the upstream project boundary.
 
-## Documentation
+## Canonical product documentation
+
+The following graph is the whole-product source of truth alongside protected-main code and root `AGENTS.md` / `ARCHITECTURE.md`:
+
+- [Product requirements](docs/PRD.md)
+- [Technical requirements](docs/TRD.md)
+- [Architecture decisions](ARCHITECTURE.md)
+- [ADR index](docs/adr/README.md)
+- [Logical data model / ERD](docs/DATA_MODEL.md)
+- [UML and interaction views](docs/UML.md)
+- [API and event contracts](docs/API_CONTRACTS.md)
+- [Threat model](docs/THREAT_MODEL.md)
+- [Privacy and data lifecycle](docs/PRIVACY_DATA_LIFECYCLE.md)
+- [Test strategy](docs/TEST_STRATEGY.md)
+- [Operability](docs/OPERABILITY.md)
+- [Release, migration, and rollback](docs/RELEASE_AND_MIGRATION.md)
+- [Standards and research traceability](docs/STANDARDS_TRACEABILITY.md)
+- [Requirements/evidence traceability](docs/TRACEABILITY.md)
+- [Documentation fitness assessment](docs/DOCUMENTATION_ASSESSMENT.md)
+- [Vulnerability reporting](SECURITY.md)
+
+Scoped feature designs, plans and runbooks remain useful evidence but do not override this code-current canonical graph.
 
-- Product and architecture design: `docs/superpowers/specs/2026-08-02-life-os-design.md`
+## Additional documentation
+
+- Product and architecture design history: `docs/superpowers/specs/2026-08-02-life-os-design.md`
 - Foundation implementation plan: `docs/superpowers/plans/2026-08-02-life-os-foundation.md`
 - Gateway service-level objectives: `docs/operations/service-level-objectives.md`
 - Planning-service service-level objectives: `docs/operations/planning-service-level-objectives.md`
@@ -120,7 +143,6 @@ The upstream project does not operate every LifeOS deployment. A self-hosting or
 - [Production Kubernetes deployment runbook](docs/operations/production-deployment.md)
 - [Upstream privacy notice](docs/legal/privacy.md)
 - [Upstream project terms](docs/legal/terms.md)
-- [Vulnerability reporting](SECURITY.md)
 
 ## Contributing
 

apps/ai-service/src/contextual-orchestrator-proposal-model.test.ts

@@ -129,7 +129,7 @@ describe('contextual orchestrator configuration', () => {
 });
 
 describe('ContextualOrchestratorProposalModel', () => {
-  it('sends a no-tools adaptive request and returns untrusted output', async () => {
+  it('sends a no-tools schema-constrained request and returns untrusted output', async () => {
     const draft = {
       summary: 'Prioritize launch readiness.',
       rationale: ['The checklist is the active critical path.'],
@@ -166,8 +166,6 @@ describe('ContextualOrchestratorProposalModel', () => {
 
     const body = JSON.parse(String(init?.body)) as Record<string, unknown>;
     expect(body.model).toBe('contextual-orchestrator');
-    expect(body.orchestration_mode).toBe('auto');
-    expect(body.include_orchestration_trace).toBe(false);
     expect(body.tools).toBeUndefined();
     expect(body.stream).toBe(false);
     expect(body.temperature).toBe(0);
@@ -181,7 +179,24 @@ describe('ContextualOrchestratorProposalModel', () => {
       content: JSON.stringify(request),
     });
 
-    expect(body.response_format).toBeUndefined();
+    const responseFormat = body.response_format as Record<string, unknown>;
+    expect(responseFormat.type).toBe('json_schema');
+    const jsonSchema = responseFormat.json_schema as Record<string, unknown>;
+    expect(jsonSchema.name).toBe('life_os_inert_proposal_draft');
+    expect(jsonSchema.strict).toBe(true);
+    const schema = jsonSchema.schema as Record<string, unknown>;
+    expect(schema.$schema).toBe('https://json-schema.org/draft/2020-12/schema');
+    expect(schema.additionalProperties).toBe(false);
+    expect(schema.required).toEqual(['summary', 'rationale', 'operations']);
+    const properties = schema.properties as Record<string, unknown>;
+    const operations = properties.operations as Record<string, unknown>;
+    const operationItem = operations.items as Record<string, unknown>;
+    expect(operationItem.oneOf).toHaveLength(3);
+    for (const variant of operationItem.oneOf as Array<
+      Record<string, unknown>
+    >) {
+      expect(variant.additionalProperties).toBe(false);
+    }
   });
 
   it('accepts one valid completion at the exact response-byte limit', async () => {

apps/ai-service/src/contextual-orchestrator-proposal-model.ts

@@ -208,21 +208,10 @@ export const CONTEXTUAL_ORCHESTRATOR_PROPOSAL_SCHEMA = deepFreeze({
   },
 });
 
-/**
- * Builds one immutable no-tools adaptive orchestration request.
- *
- * `auto` delegates model/provider choice, workflow depth, verification,
- * fallback, and known-price optimization to contextual-orchestrator. Trace
- * disclosure stays private by default, and provider-native `response_format`
- * is deliberately omitted because the gateway proxies that feature to one
- * worker instead of applying adaptive orchestration. LifeOS still validates
- * every returned proposal through its strict local domain contract.
- */
+/** Builds one immutable no-tools OpenAI-compatible structured-output request. */
 function requestBody(input: ProposalRequest): string {
   return JSON.stringify({
     model: 'contextual-orchestrator',
-    orchestration_mode: 'auto',
-    include_orchestration_trace: false,
     temperature: 0,
     stream: false,
     messages: [
@@ -232,6 +221,14 @@ function requestBody(input: ProposalRequest): string {
       },
       { role: 'user', content: JSON.stringify(input) },
     ],
+    response_format: {
+      type: 'json_schema',
+      json_schema: {
+        name: 'life_os_inert_proposal_draft',
+        strict: true,
+        schema: CONTEXTUAL_ORCHESTRATOR_PROPOSAL_SCHEMA,
+      },
+    },
   });
 }