ContextualWisdomLab · seonghobae · Aug 9, 2026 · Aug 9, 2026 · Aug 9, 2026 · Aug 9, 2026
diff --git a/docs/CONTRACTS.md b/docs/CONTRACTS.md
@@ -1,6 +1,6 @@
 # Inkspan Interface and Integration Contracts
 
-Status: Proposed canonical baseline
+Status: Protected-main canonical baseline
 
 This document is the discoverable contract index for Inkspan's public product boundaries. Protected `main` remains the implementation authority. Open pull requests may describe Proposed behavior, but they are not shipped until protected integration and exact-head acceptance.
 

diff --git a/docs/DATA_MODEL.md b/docs/DATA_MODEL.md
@@ -1,6 +1,6 @@
 # Inkspan Conceptual Data and Evidence Model
 
-Status: Proposed canonical baseline
+Status: Protected-main canonical baseline
 
 Inkspan does **not** own an application database in the current architecture. This document is a conceptual/logical model of runtime value objects, conversion/release evidence, and host-owned boundaries. It must not be read as physical DDL. Entities marked host-owned may be persisted by an embedding product, but their physical schema is outside Inkspan authority.
 

diff --git a/docs/DOCUMENTATION_FITNESS.md b/docs/DOCUMENTATION_FITNESS.md
@@ -1,10 +1,10 @@
 # Inkspan Documentation Fitness Matrix
 
-Status: Proposed canonical baseline
+Status: Protected-main canonical baseline
 
 This document answers a narrower acquisition question than the PRD or architecture: **can an independent reviewer reconstruct Inkspan's product, technical, security, data/evidence, operating, and release decisions from GitHub without relying on chat history or pull-request prose?**
 
-Protected `main` remains the implementation authority. This documentation branch is reviewable evidence, but it is **not yet a protected-main canonical baseline** until normal protected integration succeeds. Requirements implemented only on another active branch are not shipped merely because this matrix references them.
+The documentation graph is a protected-main canonical baseline. Protected `main` remains the implementation authority, while requirements implemented only on another active branch are not shipped merely because this matrix references them.
 
 ## Classification vocabulary
 
@@ -91,11 +91,11 @@ The documentation pack itself is substantially complete for acquisition review,
 1. Issue #74 remains `planned`: the identity-only migration-routing API must still be implemented test-first while the current parser remains strict. Its architectural decision is now present rather than hidden in issue prose.
 2. Issue #66 remains `planned` behind PR #65: the dependency-locked Chromium/Firefox/WebKit differential suite must still be implemented before the rich-clipboard release line. Its release-assurance decision is now present rather than hidden in issue prose.
 3. SafeClipboard (PR #65) remains `implemented_on_active_pr` until protected integration. Autosave lifecycle observation, security disclosure, toolbar shortcut accessibility metadata, SSR/native-form serialization, revision-scoped selection evidence, and document-transition evidence are now `implemented_on_protected_main` and must not be described as active-only work.
-4. The canonical documentation branch must still reconcile its ancestry with the latest protected `main` before protected merge; protected-main identity must be refetched rather than hard-coded as timeless architecture.
+4. The canonical documentation graph is already integrated on protected `main`; future reconciliation is required only when protected source, accepted decisions, or implementation maturity materially changes.
 5. Documentation becoming mergeable or protected-merged is not a reason for the commercial loop to stop; the next safe product, release, security, accessibility or interoperability lane must continue.
 
 ## Sufficiency decision
 
-For this active documentation branch, PRD, TRD, Architecture, ADR, UML, conceptual ERD/data model, contracts, threat model, test strategy, operability, security disclosure, and traceability are `present_current` for the durable product and accepted/planned architecture decisions reconstructed from the conversation and live repository. Autosave lifecycle observation, the security disclosure lifecycle, toolbar shortcut accessibility metadata, SSR/native-form serialization, revision-scoped selection evidence, and document-transition evidence are `implemented_on_protected_main`. SafeClipboard remains active-PR work. Envelope migration routing and cross-engine browser assurance are explicit Proposed ADR decisions while their implementations remain `planned`. A physical relational ERD is `not_applicable` because Inkspan deliberately owns no application persistence.
+PRD, TRD, Architecture, ADR, UML, conceptual ERD/data model, contracts, threat model, test strategy, operability, security disclosure, and traceability are `present_current` for the durable product and accepted/planned architecture decisions reconstructed from the conversation and live repository. Autosave lifecycle observation, the security disclosure lifecycle, toolbar shortcut accessibility metadata, SSR/native-form serialization, revision-scoped selection evidence, and document-transition evidence are `implemented_on_protected_main`. SafeClipboard remains active-PR work. Envelope migration routing and cross-engine browser assurance are explicit Proposed ADR decisions while their implementations remain `planned`. A physical relational ERD is `not_applicable` because Inkspan deliberately owns no application persistence.
 
-No material product architecture decision identified by this review remains only in chat or issue prose. Accordingly, the **documentation design is sufficient as a proposed acquisition baseline**, but the repository is **not yet a protected-main canonical baseline** until this graph is reconciled with the latest protected source generation and passes normal protected integration. Product/release readiness must continue to be evaluated independently of documentation completeness.
+No material product architecture decision identified by this review remains only in chat or issue prose. Accordingly, the **documentation graph is a protected-main canonical baseline** and is sufficient for acquisition reconstruction under the current product boundary. Product/release readiness must continue to be evaluated independently of documentation completeness.
diff --git a/docs/OPERABILITY.md b/docs/OPERABILITY.md
@@ -1,6 +1,6 @@
 # Inkspan Operability and Recovery
 
-Status: Proposed canonical baseline
+Status: Protected-main canonical baseline
 
 ## Operational model
 

diff --git a/docs/PRD.md b/docs/PRD.md
@@ -1,6 +1,6 @@
 # Inkspan Product Requirements
 
-Status: Proposed canonical baseline
+Status: Protected-main canonical baseline
 
 ## Product definition
 
@@ -129,4 +129,4 @@ Shareable acquisition evidence excludes production tenant content and credential
 
 Protected `main` is the sole implemented baseline. Open PRs may describe Proposed or Active work but are not shipped contracts until protected integration. Canonical documentation must state when a requirement is target architecture rather than current implementation.
 
-Lifecycle observation is implemented on protected `main`. The root security disclosure lifecycle, toolbar shortcut accessibility metadata, SSR/native-form serialization, revision-scoped selection evidence, and document-transition evidence are also implemented on protected `main`. Current open development lines include SafeClipboard and canonical documentation reconciliation. Cross-engine browser assurance remains planned behind SafeClipboard, and a future envelope-identity migration-routing API is tracked separately and must preserve host migration ownership.
+Lifecycle observation is implemented on protected `main`. The root security disclosure lifecycle, toolbar shortcut accessibility metadata, SSR/native-form serialization, revision-scoped selection evidence, and document-transition evidence are also implemented on protected `main`. SafeClipboard remains the current active product line. Cross-engine browser assurance remains planned behind SafeClipboard, and a future envelope-identity migration-routing API is tracked separately and must preserve host migration ownership.
diff --git a/docs/README.md b/docs/README.md
@@ -1,6 +1,6 @@
 # Inkspan canonical documentation
 
-Status: Proposed canonical baseline
+Status: Protected-main canonical baseline
 
 This directory is the discoverable index for Inkspan's product, technical, security, operability, and architecture records. Protected `main` is the implementation authority. Proposed or active-PR behavior must remain labeled as such until it reaches protected `main` with the required evidence.
 

diff --git a/docs/TEST_STRATEGY.md b/docs/TEST_STRATEGY.md
@@ -1,6 +1,6 @@
 # Inkspan Test Strategy
 
-Status: Proposed canonical baseline
+Status: Protected-main canonical baseline
 
 ## Purpose
 

diff --git a/docs/THREAT_MODEL.md b/docs/THREAT_MODEL.md
@@ -1,6 +1,6 @@
 # Inkspan Threat Model
 
-Status: Proposed canonical baseline
+Status: Protected-main canonical baseline
 
 ## Scope and trust boundary
 

diff --git a/docs/TRACEABILITY.md b/docs/TRACEABILITY.md
@@ -1,6 +1,6 @@
 # Inkspan Standards and Evidence Traceability
 
-Status: Proposed canonical baseline
+Status: Protected-main canonical baseline
 
 ## Purpose
 

diff --git a/docs/TRD.md b/docs/TRD.md
@@ -1,6 +1,6 @@
 # Inkspan Technical Requirements
 
-Status: Proposed canonical baseline
+Status: Protected-main canonical baseline
 
 ## Authority and runtime boundary
 

diff --git a/docs/UML.md b/docs/UML.md
@@ -1,6 +1,6 @@
 # Inkspan Runtime Diagrams
 
-Status: Proposed canonical baseline
+Status: Protected-main canonical baseline
 
 These diagrams describe the accepted product boundary. Protected `main` remains implementation authority; elements owned by open PRs are Proposed until integrated.
 

diff --git a/src/canonicalProductDocumentation.test.ts b/src/canonicalProductDocumentation.test.ts
@@ -227,7 +227,8 @@ describe('canonical product documentation graph', () => {
     expect(fitness).toContain('physical relational ERD');
     expect(fitness).toContain('not_applicable');
     expect(fitness).toContain('Protected `main`');
-    expect(fitness).toContain('not yet a protected-main canonical baseline');
+    expect(fitness).toContain('documentation graph is a protected-main canonical baseline');
+    expect(fitness).not.toContain('not yet a protected-main canonical baseline');
   });
 
   it('keeps offline font provenance and network-free asset contracts explicit', () => {

diff --git a/src/canonicalProtectedBaseline.test.ts b/src/canonicalProtectedBaseline.test.ts
@@ -0,0 +1,43 @@
+import { readFileSync } from 'node:fs';
+import { resolve } from 'node:path';
+
+import { describe, expect, it } from 'vitest';
+
+const repositoryFile = (path: string): string =>
+  readFileSync(resolve(process.cwd(), path), 'utf8');
+
+const protectedBaselineDocuments = [
+  'docs/README.md',
+  'docs/DOCUMENTATION_FITNESS.md',
+  'docs/PRD.md',
+  'docs/TRD.md',
+  'docs/CONTRACTS.md',
+  'docs/UML.md',
+  'docs/DATA_MODEL.md',
+  'docs/THREAT_MODEL.md',
+  'docs/TEST_STRATEGY.md',
+  'docs/OPERABILITY.md',
+  'docs/TRACEABILITY.md',
+] as const;
+
+describe('protected-main canonical documentation baseline', () => {
+  it('marks the integrated canonical graph as protected-main authority', () => {
+    for (const path of protectedBaselineDocuments) {
+      expect(repositoryFile(path), path).toContain(
+        'Status: Protected-main canonical baseline',
+      );
+    }
+  });
+
+  it('does not retain pre-integration branch disclaimers after protected merge', () => {
+    const fitness = repositoryFile('docs/DOCUMENTATION_FITNESS.md');
+
+    expect(fitness).not.toContain('not yet a protected-main canonical baseline');
+    expect(fitness).not.toContain(
+      'canonical documentation branch must still reconcile its ancestry',
+    );
+    expect(fitness).toContain(
+      'documentation graph is a protected-main canonical baseline',
+    );
+  });
+});