# OCP next-release package inventory and migration plan

> **Historical planning record.** This inventory describes the pre-0.4 workspace snapshot inspected on 12 August 2026. OCP 0.4 now supersedes the implementation-facing baseline described below. Paths and commands are historical logical examples, not statements about the current package; use the release-root `README.md` for current reproduction instructions.

**Snapshot date:** 2026-08-12  
**Workspace:** historical OCP project workspace (location-independent reference)  
**Scope:** Read-only inspection of the OCP deliverables, source/build work, schemas, examples, conformance assets, DOCX/XLSX generation, reviewer inputs, and duplicate/stale artifacts. No deliverable was edited by this inventory.

## Executive verdict

The workspace contains a **validated OCP 0.2 review snapshot**, but it does not yet contain a single reproducible source tree for the proposed next release.

- `deliverables/OCP-v0.2-Review-Draft.md` is the declared and most complete human-readable authority for the 0.2 review draft.
- `deliverables/OCP-Schema-and-Conformance-Pack/` is the active 0.2 executable package. Its checked-in validators and fixtures pass, but several scripts under `work/` are older than the package they appear to generate and would regress it if rerun.
- Root-level `Open-Continuity-Protocol-OCP-v0.4-Synthesis-Draft.docx` and `OCP-v0.4-Synthesis-Decision-Register.xlsx` are the latest synthesis artifacts, but no matching **canonical** Markdown/JSON sources, package, builder, or validator exists. A Pandoc-style extraction exists at `work/synthesis_extract/OCP-v0.4-Synthesis-Draft.md`; it is a derived inspection copy, not an authored source. The binaries are authoritative **synthesis inputs**, not a reproducible release.
- `deliverables/OCP-Schema-and-Conformance-Pack.zip` is the clean current archive. `deliverables/OCP-Schema-and-Conformance-Pack 2.zip` is an older Finder-created duplicate and must not ship.
- The next externally reviewable release should be named **`0.4-review-draft`**, built in a new versioned tree, and distributed as one deterministic package. Do not overwrite 0.2 and do not label the result stable `0.4` or `1.0` until independent interoperability evidence exists.

The release gate implied by the process brief is therefore: normalize the 0.4 synthesis into source-controlled text/data, reconcile it with the validated 0.2 machine pack, replace the stale one-shot builders with a single idempotent build, regenerate all derivatives, and rerun structural, semantic, document, spreadsheet, and archive validation.

## 1. Current-state authority map

Authority here means “the best current source for this layer,” not “ready to publish.”

| Layer | Current best evidence | Current status | Release implication |
|---|---|---|---|
| Original review baseline | `Open-Continuity-Protocol-OCP-v0.1-Working-Draft-ChatGPT.docx` | Source document reviewed to produce 0.2; approximately 12,515 words | Preserve by checksum in history; do not edit in place |
| 0.2 normative prose | `deliverables/OCP-v0.2-Review-Draft.md` | Declared canonical standalone spec; 3,761 lines, approximately 24,995 words, 45 top-level sections, 23 JSON blocks | Treat as the 0.2 prose authority during migration |
| 0.2 publishing edition | `deliverables/OCP-v0.2-Review-Draft.docx` | Generated derivative; approximately 24,468 words, 45 H1, 228 H2, 49 hyperlinks; final internal render/a11y evidence exists | Never hand-edit; regenerate from canonical Markdown |
| 0.2 PDF | `deliverables/OCP-v0.2-Review-Draft.pdf` | Undocumented Word-generated derivative; 118 pages. It differs from the 114-page LibreOffice QA render | Exclude from the next distribution unless rebuilt and visually verified from the final DOCX |
| 0.2 executable model | `deliverables/OCP-Schema-and-Conformance-Pack/` | Active package: 18 schemas, 20 positive examples, 21 negative example/expectation pairs, 3 registries, 44 semantic cases, and 54 assertions | Use as the machine-readable migration base, not the stale `work/` generators |
| 0.2 issue register | `deliverables/OCP-Issue-Register.xlsx`, sourced from `work/issue_register.json` | 57-row reviewer issue register with formulas, charts, validations, and conditional formatting | Preserve as 0.2 review history; do not confuse with the newer synthesis register |
| 0.4 synthesis prose | `Open-Continuity-Protocol-OCP-v0.4-Synthesis-Draft.docx` | Latest prose synthesis; 6,397 words, 19 H1, 59 H2, 33 tables, 17 code blocks, no hyperlinks/tracked changes. It contains schema excerpts, not a complete machine package | Import into canonical Markdown and prove content parity before it can become release authority |
| 0.4 synthesis decisions | `OCP-v0.4-Synthesis-Decision-Register.xlsx` | 7 sheets; 25 decisions, 57 issues, 9 core objects, 5 initial profile families, 5 future profiles, and 10 P0 items. Static binary; no source builder/data found | Normalize to JSON/CSV source data and generate the workbook from it |
| 0.9 architectural predecessor | `OCP-Specification-v0.9-draft.md`, `build_ocp_spec.py`, and `Open-Continuity-Protocol-OCP-v0.9-Draft.docx` | Earlier architectural branch with its own builder; not the base selected by the 0.1/0.2 review stream | Archive as design history. Reuse only explicitly retained invariants, not the prior HIC/admissibility architecture wholesale |
| Original independent-review assignment | `review/source-feedback-manifest.json#governing_assignment` (`review-input:ASSIGNMENT-1`) | Complete 1,968-line board/editor assignment that requested the 0.2 review draft and machine companion | Preserve as review provenance and requirements evidence |
| Reviewer inputs | `review/source-feedback-manifest.json` logical inputs `INPUT-1` through `INPUT-3` | Three distinct review/synthesis inputs | Record each once with hash, author/model/provenance if known, and disposition |
| Next-release process brief | `review/source-feedback-manifest.json` logical inputs `INPUT-4` through `INPUT-8` | All five files are byte-identical (`SHA-256 91aea79c0e6a01de90cb01e6a1465c4ff76586d36307c2422fc1dd62d9674c56`) | Record one process requirement source plus four duplicate aliases; do not count them as five independent reviews |

### Current hashes useful for freezing the migration baseline

| Artifact | SHA-256 |
|---|---|
| `deliverables/OCP-v0.2-Review-Draft.md` | `e987cce1b102c23b23eed242ea79023fbba63b9316776b7580eb8faf36dcfd77` |
| `deliverables/OCP-v0.2-Review-Draft.docx` | `859b05360d36413367b7f3dd31e857c10eface76cc7280847c4d96d51812a57b` |
| `deliverables/OCP-Schema-and-Conformance-Pack.zip` | `f6d408aa8533de8ac4068e2a35ba89ea798b56f1b83cc70dfc76d812a73d8a4f` |
| `deliverables/OCP-Schema-and-Conformance-Pack 2.zip` | `58abfef6b0240217a783bc5314cb72d3d7e9ae73ce03b1914287b79cb19ff528` |
| `Open-Continuity-Protocol-OCP-v0.4-Synthesis-Draft.docx` | `c2f69ade04c8edbb921dc7a1a3c6898f5dc37b9c40a8a3bbb538d03923527d2d` |
| `OCP-v0.4-Synthesis-Decision-Register.xlsx` | `29437349d5fd816546a69cdebb3161f2caa118858ce46eaccccfd1c95285f951` |
| original assignment `ASSIGNMENT-1` | `f78bf92777700094a0eb5f6a02b07d733f0d5f655edff180c3b4d0c02f17e142` |
| reviewer input `INPUT-1` | `f3dd9cd9216a0cb8998fc872039466bb31fdc8a574bba3417078eae2b50dcb05` |
| reviewer input `INPUT-2` | `057779c77f78e1e23bf35abff5dfad9d90959820141db15169e00f40d9063266` |
| reviewer input `INPUT-3` | `a7a179e64583d492934a2efa34f9cd9187659cdc0c1594424a07f2f84081d09e` |
| each of `INPUT-4` through `INPUT-8` | `91aea79c0e6a01de90cb01e6a1465c4ff76586d36307c2422fc1dd62d9674c56` |

These hashes are exact for the inspected snapshot. Recompute them immediately before moving or renaming anything and commit the resulting full manifest with the migration.

## 2. Active 0.2 machine package

Excluding `node_modules`, `.DS_Store`, and editor lock files, the active package contains **96 files**:

| Area | Count | Notes |
|---|---:|---|
| Package root | 7 | `README.md`, `VALIDATION.md`, `package.json`, `package-lock.json`, `validate.cjs`, `validation-report.json`, `semantic-validation-report.json` |
| Core/object schemas | 11 | `common`, `context-space`, `source-record`, `context-item`, `client-declaration`, `context-request`, `grant-receipt`, `context-package`, `update-proposal`, `review-decision`, `transfer-manifest` |
| Profile schemas | 5 | conversation, message, artifact descriptor, lineage event, erasure status record |
| Offline-transfer assets | 2 | schema plus extension template |
| Adapter schemas | 1 | Adapter extension surface |
| OpenAPI binding | 1 | HTTP/API description |
| Registries | 3 | Lifecycle, event, and error registries |
| Conformance assets | 4 | Assertions, availability, semantic fixtures, semantic validator |
| Positive examples | 20 | Expected to validate |
| Negative examples and expectations | 42 | 21 invalid instances paired with 21 expectation files |

The package pins Ajv 8.20.0 and `ajv-formats` 3.0.1 through `package-lock.json`. Keep the lockfile; recreate dependencies with `npm ci` instead of distributing `node_modules`.

### Fresh read-only verification result

A clean copy of the current package was made under `/tmp`, dependencies were made available there, and its own test commands passed:

- schemas: **18/18**
- positive examples: **20/20**
- negative examples: **21/21**
- registries: **3/3**
- semantic fixtures: **44/44**

The availability matrix correctly identifies remote-security and offline-transfer-protection checks as unavailable rather than falsely claiming coverage. This is validation of the local 0.2 package, not evidence of a published release or two independent implementations.

## 3. Build and generation map

### Prose and DOCX

Observed 0.2 publishing flow:

```text
deliverables/OCP-v0.2-Review-Draft.md
  -> work/build_docx_source.mjs
  -> work/docx/OCP-v0.2-Review-Draft.source.md
  -> work/build_reference_docx.py
  -> work/docx/OCP-reference.docx
  -> [Pandoc invocation not captured in a single checked-in entrypoint]
  -> work/docx/OCP-v0.2-Review-Draft.base.docx
  -> work/postprocess_ocp_docx.py
  -> deliverables/OCP-v0.2-Review-Draft.docx
  -> render, pagination, visual, XML, and accessibility QA
```

Relevant files:

- `work/build_docx_source.mjs` prepares the 0.2 DOCX-oriented Markdown.
- `work/build_reference_docx.py` creates the Word style reference.
- `work/postprocess_ocp_docx.py` performs final DOCX surgery and is hard-coded to 0.2 paths.
- `work/docx/render_publication_final/` is the strongest final rendering evidence: 114 pages plus a zero-finding accessibility JSON report.
- `work/qa_spec.mjs` checks the 0.2 Markdown, but it is hard-coded to 0.2 counts and the exact 45-section outline.
- `work/sync_spec_pack_json.mjs`, `work/append_spec_examples.mjs`, and `work/append_spec_tail.mjs` are one-way/one-shot 0.2 assembly tools, not a reusable build system.

There is no complete, recorded command that deterministically produces the base DOCX from the DOCX source and reference document. The next release must put that invocation behind one checked-in command and treat DOCX/PDF as generated artifacts.

No source or build pipeline was found for the root-level 0.4 synthesis DOCX.

`work/synthesis_extract/OCP-v0.4-Synthesis-Draft.md` is a useful text extraction of that DOCX, and `work/xlsx_inspect/inspect_synthesis.mjs` is a useful read-only workbook inspection helper. Neither is a source generator: the extraction retains conversion artifacts such as raw HTML tables and hard line wrapping, and the workbook helper imports/inspects rather than rebuilding the XLSX.

### Schemas, examples, and conformance

The executable authority is inside `deliverables/OCP-Schema-and-Conformance-Pack/`:

- `validate.cjs` is the structural/schema/registry test runner.
- `conformance/validate-semantics.mjs` is the semantic fixture runner.
- `package.json` and `package-lock.json` define the reproducible Node dependency set.

The apparent source generators under `work/` are stale relative to the active package:

| Script | What it currently emits/expects | Active package | Risk if rerun |
|---|---:|---:|---|
| `work/generate_examples.mjs` | 18 positive examples and `opencontinuity.org` identifiers | 20 positives and former placeholder identifiers | Drops two examples and reintroduces superseded identifiers |
| `work/build_companion.mjs` | 16 negative pairs, 49 assertions, 8 semantic cases, older lifecycle state/transition rules | 21 negative pairs, 54 assertions, 44 semantic cases, corrected lifecycle rules | Material conformance regression |
| `work/validate_pack.mjs` | Hard-coded plugin `node_modules` path and `opencontinuity.org` URI mapping | Package-local pinned dependencies and `.example` identifiers | Non-portable and misaligned validation |
| `work/sync_spec_pack_json.mjs` | Hard-coded 0.2 targets and partial JSON-block synchronization | Complete active pack | Can create false prose/machine parity |

This proves the current package was patched or evolved after its generator scripts. The next release must not be generated from those scripts unchanged.

### Issue-register XLSX

- `work/issue_register.json` is the editable source for the 0.2 issue register.
- `work/issue_workbook/build_issue_register.mjs` generates `deliverables/OCP-Issue-Register.xlsx`.
- `work/issue_workbook/qa-report.json` records workbook QA. The remaining freeze-pane note is a serialization/tooling limitation, not evidence of formula or data failure.
- No equivalent JSON/CSV source or builder was found for `OCP-v0.4-Synthesis-Decision-Register.xlsx`.

The next release should make the decision/issue data normative in text-based JSON or CSV and generate XLSX as a review convenience.

## 4. Duplicate, stale, and non-release artifacts

### ZIP verdict

| Archive | Structure | Contents | Treatment |
|---|---|---|---|
| `deliverables/OCP-Schema-and-Conformance-Pack.zip` | Clean flat package root | 106 ZIP entries / 96 regular package files; includes `package-lock.json`; excludes dependencies and Finder metadata; byte-matches the active package after exclusions | Keep as the sole 0.2 archive until 0.2 is moved to immutable history |
| `deliverables/OCP-Schema-and-Conformance-Pack 2.zip` | Finder wrapper directory | 108 entries; includes `.DS_Store` and `__MACOSX`/AppleDouble data; omits `package-lock.json` | Move to a duplicate quarantine/archive or delete after hash manifest and owner confirmation; never ship |

Both archives pass ZIP integrity checks. Integrity alone does not make the second archive suitable for release.

### `node_modules` verdict

`deliverables/OCP-Schema-and-Conformance-Pack/node_modules/` contains approximately 545 files and 2.8 MB. It is a local dependency cache, not source or a distributable asset.

- Exclude it from Git/source manifests, release staging, ZIPs, document bundles, and checksum manifests.
- Retain `package-lock.json`.
- Require a supported Node version in `README.md`/CI and run `npm ci` in a clean checkout.
- If the active directory is retained as a development checkout, `node_modules` may remain locally, but it must never be treated as package evidence.

### Other stale or historical surfaces

- `deliverables/~$...` and root `~$...` files are Word/Excel lock remnants; exclude from staging and remove once no Office process owns them.
- `.DS_Store` and `__MACOSX` are OS metadata; exclude everywhere.
- `work/schema_agent_pack/` is a superseded alternative schema family (5 schemas, 12 positives, 17 negatives, older `context_grant`, and old identifiers). Archive as analysis history; do not merge it into the active pack.
- `work/source_extract/source.md` and `work/schema_agent_pack/extract/source.md` are derived extractions from the 0.1 DOCX, not normative sources.
- `.ocp_work/`, `.ocp_render_v1/`, `.ocp_render_v2/`, `.ocp_render_v3/`, and most of `work/docx/` are large build/render caches. Keep outside every release. After release, retain final reports, checksums, and selected contact sheets; archive or prune page-image intermediates separately.
- Root `build_ocp_spec.py` and `.ocp_work/build_ocp_spec.py` are different v0.9-era builders with different inputs. They must not remain visually adjacent to the active next-release entrypoint without an explicit `archive/legacy-v0.9/` boundary.
- `deliverables/OCP-v0.2-Review-Draft.pdf` is not listed in the deliverables README and does not match the strongest QA render pagination. Quarantine it as an unverified derivative or replace it only with a newly verified PDF.

## 5. Recommended exact next-release layout

Use one versioned source tree and one generated distribution directory. The versioned tree is the review-draft source of truth; `dist/` is disposable and reproducible.

```text
releases/
  0.4-review-draft/
    README.md
    VERSION
    RELEASE-MANIFEST.json
    package.json
    package-lock.json
    spec/
      OCP-v0.4-Review-Draft.md
    schemas/
      common.schema.json
      core/
        *.schema.json
      profiles/
        *.schema.json
      adapters/
        *.schema.json
    examples/
      positive/
        *.json
      negative/
        *.json
        *.expected.json
      semantic/
        *.json
    conformance/
      assertions.json
      availability.json
      semantic-fixtures.json
      validate.cjs
      validate-semantics.mjs
    registries/
      lifecycles.json
      events.json
      errors.json
    bindings/
      http/
        openapi.json
      offline/
        *.json
    review/
      decision-register.json
      issue-register.json
      source-feedback-manifest.json
      OCP-v0.4-Executive-Review-Summary.md
      OCP-v0.4-Change-Log.md
      OCP-v0.2-to-v0.4-Migration.md
    tools/
      build-release.mjs
      build-docx.mjs
      build-review-workbook.mjs
      qa-spec.mjs
      validate-release.mjs
    dist/
      Open-Continuity-Protocol-OCP-v0.4-Review-Draft.docx
      Open-Continuity-Protocol-OCP-v0.4-Review-Draft.pdf
      OCP-v0.4-Review-Decision-Register.xlsx
      OCP-v0.4-Review-Draft-Package.zip
      validation-report.json
      semantic-validation-report.json
      document-qa-report.json
      workbook-qa-report.json
      SHA256SUMS
archive/
  0.2-review-draft/
    [frozen current 0.2 deliverables plus full SHA-256 manifest]
  legacy-v0.9/
    [v0.9 Markdown, builders, DOCX, and selected validation evidence]
  analysis/
    [superseded schema-agent pack, source extractions, and reviewer working files]
```

Rules for this layout:

1. `spec/OCP-v0.4-Review-Draft.md`, JSON schemas/data, and text-based review registers are editable authorities.
2. DOCX, PDF, XLSX, reports, and ZIP are generated only into `dist/`; they are never edited as primary sources.
3. `RELEASE-MANIFEST.json` records release label, wire version, status, source hashes, tool/runtime versions, generated artifact hashes, and known unavailable checks.
4. `dist/` is erased/rebuilt by the release tool, never incrementally hand-patched.
5. `node_modules`, `.DS_Store`, `__MACOSX`, `~$*`, render PNGs, temporary DOCX files, and analysis work are forbidden by a manifest/ZIP linter.
6. The release ZIP contains the versioned source/package content and verified public derivatives, under one stable top-level directory such as `OCP-v0.4-Review-Draft/`; it does not contain the workspace `archive/` or build cache.

## 6. Version and authority strategy

### Release label

Use **`0.4-review-draft`** for paths, filenames, README labels, and review communications. “Synthesis” describes the current input artifact, not the release status after normalization. Do not promote to stable `0.4` or `1.0` yet.

### Wire version

The synthesis artifacts currently say document `0.4-synthesis-draft` and wire `0.4-draft`, whereas the active 0.2 pack uses `0.2`. Before changing schema constants, make one explicit architecture decision and apply it everywhere:

- recommended: wire `ocp_version: "0.4"` with a separate release-status field/manifest value `review-draft`; or
- if prerelease syntax is deliberately part of the protocol, use `0.4-draft` consistently and test every version comparison and schema constraint.

Do not silently mix `0.4`, `0.4-draft`, `0.4-review-draft`, and `0.4-synthesis-draft` across prose, examples, schemas, and OpenAPI.

### Source authority

The release manifest should establish this order:

1. Normative prose: versioned Markdown spec.
2. Normative executable definitions: versioned schemas, registries, conformance assertions, and binding definitions.
3. Normative decisions/issues: text-based JSON source with stable IDs and dispositions.
4. Generated review/publication forms: DOCX, PDF, and XLSX.
5. Historical inputs: v0.1, v0.2, v0.9, reviewer responses, synthesis binaries, and extracted text.

Prose and executable definitions must agree, but neither should be silently regenerated from embedded snippets in the other. The build should verify their shared identifiers/version/enum/example invariants.

## 7. Migration sequence

1. **Freeze the current evidence.** Generate full SHA-256 manifests for the 0.1 baseline, all 0.2 deliverables, both 0.4 synthesis binaries, the clean ZIP, and reviewer inputs. Record timestamps and provenance without moving files yet.
2. **Create the new versioned tree.** Copy the clean 0.2 machine package as the executable starting point, excluding `node_modules` and OS/editor metadata. Copy the 0.2 Markdown as the prose comparison base.
3. **Normalize the synthesis.** Convert the 0.4 DOCX into `spec/OCP-v0.4-Review-Draft.md`; convert the decision workbook into stable JSON records. Preserve all decision/issue IDs. Compare text, tables, code blocks, headings, and counts against the binaries before declaring parity.
4. **Normalize reviewer provenance.** Store hashes and dispositions for the three distinct reviewer inputs. Represent pasted-text files 4–8 as one process brief with duplicate aliases.
5. **Resolve the model delta.** Apply each accepted 0.4 decision to prose, schemas, examples, lifecycle registries, OpenAPI, assertions, and semantic fixtures together. Record every 0.2-to-0.4 breaking/non-breaking change in the migration document.
6. **Replace stale builders.** Consolidate schema/example/conformance generation and validation behind `tools/build-release.mjs` and `tools/validate-release.mjs`. Make them idempotent, package-local, path-independent, and pinned by the lockfile.
7. **Make document generation reproducible.** Capture the exact Markdown-to-DOCX command, reference-document generation, post-processing, PDF export, XML checks, full-page rendering, and accessibility audit behind `tools/build-docx.mjs`.
8. **Generate the workbook.** Build XLSX from `decision-register.json` and `issue-register.json`; then inspect every sheet, formulas, validations, charts, widths, wrapping, freeze panes, and renderings.
9. **Run cross-layer validation.** Validate all examples, negative expectations, registries, semantic fixtures, OpenAPI references, assertion coverage, version strings, links, prose-embedded examples, and migration claims.
10. **Stage deterministically.** Build a fresh `dist/`, generate one clean top-level ZIP, create `SHA256SUMS`, inspect the archive listing, extract to a temporary directory, run `npm ci && npm test` there, and compare extracted files to the manifest.
11. **Archive only after acceptance.** Move 0.2, v0.9, superseded schema work, and duplicate artifacts out of active surfaces only after the new manifest and release candidate are reviewed. Deletion of the dirty duplicate ZIP should be a separate, explicit cleanup action.

## 8. Validation commands

These commands are proposed release gates. Run them from the workspace root unless a command changes directory. They intentionally avoid dependency or cache content in the release artifact.

### JSON syntax and forbidden-file checks

```bash
find releases/0.4-review-draft -type f -name '*.json' \
  -not -path '*/node_modules/*' -print0 | xargs -0 -n1 jq empty

find releases/0.4-review-draft \
  \( -name node_modules -o -name .DS_Store -o -name '__MACOSX' -o -name '~$*' \) \
  -print
```

The second command must produce no output.

### Package validation from a clean dependency install

```bash
cd releases/0.4-review-draft
npm ci
npm test
node conformance/validate-semantics.mjs
node tools/validate-release.mjs
```

The validator should fail unless all schema examples, negative expectations, registry references, semantic fixtures, assertion mappings, OpenAPI references, release-manifest hashes, and declared version strings pass. Unavailable checks must be explicit in `conformance/availability.json` and the report.

### Cross-version and stale-identifier scan

```bash
rg -n '0\.1|0\.2|0\.3|0\.3-draft|0\.3-review-draft|0\.3-synthesis-draft' \
  releases/0.4-review-draft \
  -g '!node_modules/**' -g '!dist/**'

rg -n 'opencontinuity\.org|opencontinuity\.example' \
  releases/0.4-review-draft \
  -g '!node_modules/**' -g '!dist/**'
```

Review every match. The first scan is not expected to be empty because migration prose will mention prior versions; machine-readable fields and normative examples must use the chosen value consistently. The second scan must enforce the deliberately chosen identifier domain rather than allowing both accidentally.

### Build and QA generated documents

The new release entrypoint should encapsulate the currently missing Pandoc/reference/post-processing invocation:

```bash
cd releases/0.4-review-draft
npm run build:docx
npm run build:pdf
npm run qa:documents
unzip -t dist/Open-Continuity-Protocol-OCP-v0.4-Review-Draft.docx
unzip -p dist/Open-Continuity-Protocol-OCP-v0.4-Review-Draft.docx word/document.xml \
  | rg -n 'Open Continuity Protocol|0\.3|ocp_version|source_authority|runtime_source'
```

`qa:documents` should render **every page**, inspect contact sheets and representative full-resolution pages, check page count/orphans/blank pages/clipping, verify hyperlinks and heading structure through OOXML, and run an accessibility audit. PDF text extraction alone is insufficient evidence for code blocks or schema content.

### Build and QA the review workbook

```bash
cd releases/0.4-review-draft
npm run build:workbook
npm run qa:workbook
unzip -t dist/OCP-v0.4-Review-Decision-Register.xlsx
```

The workbook QA must compare source JSON IDs/counts/statuses to every generated sheet and verify formulas, tables, filters, validation lists, freeze panes, column widths, wrapping, chart ranges, and rendered sheets.

### Deterministic ZIP staging

The release script should implement the equivalent of the following in a disposable staging directory:

```bash
ocp_stage_parent="$(mktemp -d)"
ocp_stage="$ocp_stage_parent/OCP-v0.4-Review-Draft"
ocp_archive="$(pwd)/releases/0.4-review-draft/dist/OCP-v0.4-Review-Draft-Package.zip"
mkdir -p "$ocp_stage"
rsync -a \
  --exclude node_modules \
  --exclude .DS_Store \
  --exclude '__MACOSX' \
  --exclude '~$*' \
  --exclude 'dist/OCP-v0.4-Review-Draft-Package.zip' \
  releases/0.4-review-draft/ "$ocp_stage/"
find "$ocp_stage" -exec touch -t 198001010000 {} +
(
  cd "$ocp_stage_parent"
  LC_ALL=C find OCP-v0.4-Review-Draft -type f -print \
    | LC_ALL=C sort \
    | zip -X -q \
        "$ocp_archive" -@
)
```

Then verify the artifact independently:

```bash
unzip -t releases/0.4-review-draft/dist/OCP-v0.4-Review-Draft-Package.zip
zipinfo -1 releases/0.4-review-draft/dist/OCP-v0.4-Review-Draft-Package.zip \
  | rg '(^|/)(node_modules|\.DS_Store|__MACOSX|~\$)' && exit 1 || true

ocp_extract="$(mktemp -d)"
unzip -q releases/0.4-review-draft/dist/OCP-v0.4-Review-Draft-Package.zip \
  -d "$ocp_extract"
(
  cd "$ocp_extract/OCP-v0.4-Review-Draft"
  npm ci
  npm test
  node conformance/validate-semantics.mjs
  node tools/validate-release.mjs
)
```

Generate checksums without hashing `SHA256SUMS` into itself:

```bash
(
  cd releases/0.4-review-draft/dist
  find . -maxdepth 1 -type f ! -name SHA256SUMS -print \
    | LC_ALL=C sort \
    | xargs shasum -a 256 > SHA256SUMS
)
(
  cd releases/0.4-review-draft/dist
  shasum -a 256 -c SHA256SUMS
)
```

### Current 0.2 snapshot checks, if a baseline rerun is needed

Run in a disposable copy, not by mutating the frozen deliverables directory:

```bash
ocp_baseline="$(mktemp -d)"
unzip -q deliverables/OCP-Schema-and-Conformance-Pack.zip -d "$ocp_baseline"
(
  cd "$ocp_baseline"
  npm ci
  npm test
  node conformance/validate-semantics.mjs
)
unzip -t deliverables/OCP-Schema-and-Conformance-Pack.zip
unzip -t 'deliverables/OCP-Schema-and-Conformance-Pack 2.zip'
```

## 9. Release acceptance checklist

The next package is ready for external review only when all of the following are true:

- The 0.4 synthesis DOCX and workbook have source-controlled Markdown/JSON equivalents with demonstrated parity.
- Every open P0 and every issue marked release-blocking has an explicit resolution, deferral rationale, or unavailable-test declaration.
- The prose, schemas, examples, registries, OpenAPI, lifecycle rules, assertions, semantic fixtures, version values, and review registers agree.
- The package is reproduced from a clean checkout using only declared tools and pinned dependencies.
- DOCX and optional PDF pass structural, visual, pagination, hyperlink, code/schema, and accessibility inspection.
- XLSX is generated from text data and passes data/formula/validation/render QA.
- The single release ZIP is deterministic, contains one top-level directory, excludes dependencies and metadata, passes extraction and clean-install tests, and matches `SHA256SUMS`.
- The validation report clearly distinguishes passing local checks from unavailable remote-security/offline-transfer checks and from independent interoperability evidence.
- 0.2 remains retrievable as an immutable historical snapshot, while the duplicate dirty ZIP, editor locks, dependency cache, and render caches are absent from the active release surface.

## 10. Immediate disposition summary

| Item | Immediate treatment |
|---|---|
| `Open-Continuity-Protocol-OCP-v0.4-Synthesis-Draft.docx` | Keep as a source input; normalize to Markdown before editing/releasing |
| `OCP-v0.4-Synthesis-Decision-Register.xlsx` | Keep as a source input; normalize to JSON and make XLSX generated |
| `deliverables/OCP-v0.2-Review-Draft.md` | Freeze as 0.2 normative prose baseline |
| `deliverables/OCP-Schema-and-Conformance-Pack/` | Freeze as 0.2 executable baseline; exclude local `node_modules` from manifests/distribution |
| `deliverables/OCP-Schema-and-Conformance-Pack.zip` | Retain as the one clean 0.2 package archive |
| `deliverables/OCP-Schema-and-Conformance-Pack 2.zip` | Quarantine/archive or delete after full-hash manifest; never release |
| Root/deliverables `~$*`, `.DS_Store`, `__MACOSX` | Exclude; remove from active surfaces when safe |
| `work/generate_examples.mjs`, `work/build_companion.mjs`, `work/validate_pack.mjs` | Mark stale; do not use to rebuild the active package without reconciliation |
| `work/schema_agent_pack/` | Archive as superseded analysis |
| v0.9 sources/builders | Move under explicit legacy history; do not use as next-release base |
| render/build caches | Keep outside release; retain only selected QA evidence after acceptance |

This treatment preserves every meaningful source and evidence trail while eliminating ambiguity about what is normative, what is generated, what is historical, and what is safe to distribute.
