@stravica-ai/rcf-schemas 0.2.0

package/CHANGELOG.md

@@ -0,0 +1,62 @@
+# Changelog
+
+All notable changes to `@stravica-ai/rcf-schemas` are documented in this file.
+
+The format roughly follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and the project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). Pre-1.0 breaking changes are signalled by a minor bump per semver 0.x convention.
+
+## 0.2.0 (2026-07-02)
+
+Structural rework of every parent-child relationship in the RCF chain: each edge is now encoded exactly once, on the child, as a mandatory `<parent>Id` field. Parents no longer store child lists; walkers invert the child references at load time to build the `childrenByParent` map. This makes tree drift structurally impossible.
+
+Package moves from GitHub Packages (private, `@stravica` scope) to the public npm registry as `@stravica-ai/rcf-schemas`. The `Stravica/rcf-schemas` and `Stravica/rcf-examples` repositories are made public alongside this release.
+
+### Breaking changes
+
+- **Package name** renamed from `@stravica/rcf-schemas` to `@stravica-ai/rcf-schemas`.
+- **Publish target** moved from GitHub Packages to the public npm registry.
+- **Canonical `$id`** URLs bumped from `https://schemas.stravica.io/rcf/v0.1.0/...` to `https://schemas.stravica.io/rcf/v0.2.0/...` on every schema.
+- **`prd.schema.json`**: `requirementIds` removed. REQ carries the mandatory `prdId` back-reference (already present in 0.1.0; now the sole edge).
+- **`tad.schema.json`**: `componentIds` and `architecturalDecisionIds` removed. TAC and ADR each carry the mandatory `tadId` back-reference (already present in 0.1.0; now the sole edges).
+- **`build-sequence.schema.json`**: `fbs[]` array removed. FBS now carries `bsId`, `buildOrder`, `executionStatus`, and `dependsOnFbsIds[]`.
+- **`fbs.schema.json`**:
+  - Renamed `status` to `executionStatus` (same enum; new name makes the intent explicit and disambiguates from authoring status).
+  - Renamed `dependencies` to `dependsOnFbsIds` (same shape, mandatory with `minItems: 0`).
+  - New mandatory `buildOrder` integer (>= 1); duplicates within a BS are a walker-time validation error.
+- **`test-suite.schema.json`**: rewritten to the 0.2.0 shape:
+  - New fields: `id` (`TS-\d{3}`), `usId`, `title`, `purpose`, `testLevel` (`unit` | `integration` | `e2e` | `contract` | `manual`), `acIds[]` (mandatory, >= 1), `status` (authoring status).
+  - Inline `testCases[]` with per-TC `id` (`TC-\d{3}-<slug>`), `acId`, `description`, optional `testPointer`, and `status` (`pending` | `passing` | `failing` | `skipped`).
+  - Removed the 0.1.0 fields `acId`, `prdId`, `version`, and the `given/when/then` TC shape.
+
+### Added
+
+- **`common.schema.json`**:
+  - `adrStatus` enum gains `draft` (prepended); enum is now `["draft", "proposed", "accepted", "superseded", "deprecated"]`.
+  - New `$defs.tsId` (`^TS-\d{3}$`) and updated `$defs.tcId` (`^TC-\d{3}-[a-z0-9-]+$`) - the TC pattern now requires a slug suffix.
+- Targeted per-schema test files (`test/prd.test.js`, `test/req.test.js`, `test/tad.test.js`, `test/tac.test.js`, `test/adr.test.js`, `test/build-sequence.test.js`, `test/fbs.test.js`, `test/test-suite.test.js`) covering the 0.2.0 shape changes. Fixture coverage broadened to match.
+
+### Migration
+
+Consumers on 0.1.0 must run the tree-migration script that ships with `Stravica/rcf-build-lite`'s Phase 3.7 walker rewrite. In summary:
+
+- Drop `PRD.requirementIds`. REQ files already carry `prdId`.
+- Add `REQ.prdId` if missing (mandatory in 0.2.0).
+- Drop `TAD.componentIds` and `TAD.architecturalDecisionIds`. TAC and ADR files already carry `tadId`.
+- Drop `BS.fbs[]`. For each FBS in the old array, on the corresponding FBS file set `bsId`, `buildOrder` (from the slot's `order`), `executionStatus` (from the slot's `status`), and `dependsOnFbsIds` (defaults to `[]`).
+- Rename any existing `FBS.status` to `FBS.executionStatus` and any `FBS.dependencies` to `FBS.dependsOnFbsIds`.
+- Rewrite any existing `test-suite/*.json` to the new shape (one TS per US, with inline TCs).
+
+The build-lite Phase 3.7 PR carries a `scripts/migrate-to-0.2.0.js` that performs this deterministically for a dogfood tree.
+
+## 0.1.0 (initial release)
+
+The first private release of the RCF JSON Schema bundle.
+
+- 11 schema files in `schemas/`: `common`, `prd`, `req`, `user-story`, `tad`, `tac`, `adr`, `build-sequence`, `fbs`, `test-suite`, `manifest`.
+- Per-schema docs in `docs/` (one page per schema) plus cross-cutting `id-conventions.md` and `file-layout.md`.
+- JSON test fixtures in `fixtures/valid/` and `fixtures/invalid/` covering every schema.
+- Strict by default (`additionalProperties: false`) on every object schema.
+- Cross-file `$ref` via `common.schema.json`: shared id patterns, status enums, version string, timestamp format, and `docRef` shape live in one place.
+- Canonical `$id` URLs (`https://schemas.stravica.io/rcf/v0.1.0/<name>.schema.json`) declared from the first release; the host goes live at Phase 9.
+- Apache 2.0 license.
+
+Published as `@stravica/rcf-schemas@0.1.0` on GitHub Packages with `--access restricted` (private during the build phase; public flip in 0.2.0 alongside the npm move).

package/LICENSE

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright 2026 Stravica
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/README.md

@@ -0,0 +1,165 @@
+# @stravica-ai/rcf-schemas
+
+JSON Schemas for the [Requirements Confidence Framework (RCF)](https://stravica.ai/rcf-methodology/).
+
+**Language-neutral. No code in this package, only schema files, docs, and fixtures.** Every consumer language is first-class: Node, Python, Java, or anything else with a JSON Schema 2020-12 validator.
+
+> **Status:** v0.2.0 - public preview.
+>
+> This package is available on the public npm registry as a preview. Ship-quality contract, small consumer surface. The methodology's reference implementation (`Stravica/rcf-build-lite`) is being migrated to consume 0.2.0 during Phase 3.7 of the RCF build and stays private until Phase 9; expect the public consumer path to sharpen up as that lands. If you want to experiment, `npm install @stravica-ai/rcf-schemas` is stable; docs at `https://schemas.stravica.io/` land at Phase 9.
+
+## What's here
+
+- **11 schema files** in `schemas/`:
+  - `common.schema.json` - shared `$defs` (id patterns, status enums, version, timestamp, `docRef`). Referenced via `$ref` from every other schema.
+  - `prd`, `req`, `user-story`, `tad`, `tac`, `adr`, `build-sequence`, `fbs`, `test-suite`, `manifest`.
+- **Per-schema docs** in `docs/` (one page per schema) plus cross-cutting `id-conventions.md` and `file-layout.md`.
+- **JSON test fixtures** in `fixtures/valid/` and `fixtures/invalid/` (every schema covered).
+- **CHANGELOG** in `CHANGELOG.md`.
+
+## Install
+
+### Node consumers
+
+```sh
+npm install @stravica-ai/rcf-schemas
+```
+
+The package is on the public npm registry. No scope-registry configuration is needed for installation.
+
+### Python consumers (Phase 9 onwards)
+
+```sh
+pip install stravica-rcf-schemas
+```
+
+### Java consumers (Phase 9 onwards)
+
+Maven coordinate:
+
+```
+io.stravica.rcf:rcf-schemas:0.2.0
+```
+
+### Direct fetch (Phase 9 onwards)
+
+Each schema is fetchable by its canonical `$id`:
+
+```
+https://schemas.stravica.io/rcf/v0.2.0/<name>.schema.json
+```
+
+## Use
+
+The schemas use cross-file `$ref` into `common.schema.json`. Register the bundle once at validator init; after that `$ref` resolution is transparent.
+
+### Node + ajv
+
+```js
+import Ajv from 'ajv/dist/2020.js';
+import addFormats from 'ajv-formats';
+import { readFile } from 'node:fs/promises';
+import { createRequire } from 'node:module';
+
+const require = createRequire(import.meta.url);
+const pkgRoot = require.resolve('@stravica-ai/rcf-schemas/package.json').replace(/\/package\.json$/, '');
+
+const names = [
+  'common', 'prd', 'req', 'user-story', 'tad', 'tac', 'adr',
+  'build-sequence', 'fbs', 'test-suite', 'manifest'
+];
+
+const ajv = new Ajv({ strict: true, allErrors: true });
+addFormats(ajv);
+
+for (const name of names) {
+  const schema = JSON.parse(await readFile(`${pkgRoot}/schemas/${name}.schema.json`, 'utf8'));
+  ajv.addSchema(schema);
+}
+
+const validatePrd = ajv.getSchema('https://schemas.stravica.io/rcf/v0.2.0/prd.schema.json');
+const ok = validatePrd(myPrdDoc);
+if (!ok) console.error(validatePrd.errors);
+```
+
+### Python + jsonschema
+
+```python
+from importlib.resources import files
+from jsonschema import Draft202012Validator
+from referencing import Registry, Resource
+import json
+
+# Phase 9: pip install stravica-rcf-schemas
+pkg = files('stravica_rcf_schemas') / 'schemas'
+
+names = [
+    'common', 'prd', 'req', 'user-story', 'tad', 'tac', 'adr',
+    'build-sequence', 'fbs', 'test-suite', 'manifest'
+]
+
+resources = []
+for name in names:
+    schema = json.loads((pkg / f'{name}.schema.json').read_text())
+    resources.append((schema['$id'], Resource.from_contents(schema)))
+
+registry = Registry().with_resources(resources)
+prd_schema = json.loads((pkg / 'prd.schema.json').read_text())
+validator = Draft202012Validator(prd_schema, registry=registry)
+errors = list(validator.iter_errors(my_prd_doc))
+```
+
+### Java + everit-json-schema or networknt/json-schema-validator
+
+Configure a `SchemaClient` (everit) or `SchemaLoader` (networknt) that resolves `$id` URLs from a local map populated from the bundled schemas on the classpath. See your validator's docs for the exact recipe; both libraries support multi-file `$ref` for JSON Schema 2020-12.
+
+### Any other language
+
+The schemas use JSON Schema Draft 2020-12. Any validator that supports 2020-12 + multi-file `$ref` will work. Register the 11 schemas (with `common.schema.json` first) and resolve by `$id`.
+
+## Chain shape (0.2.0)
+
+Every parent-child edge in the RCF chain is encoded exactly once, on the child, as a mandatory `<parent>Id` field. Parents never store child lists; walkers invert the child references at load time to build the `childrenByParent` map. This makes tree drift structurally impossible.
+
+- PRD is the root of the requirements chain. REQ carries `prdId`.
+- US carries `reqId` (unchanged from 0.1.0). AC lives inline in US as `acceptanceCriteria[]`.
+- TAD is the root of the architecture chain. TAC and ADR each carry `tadId`.
+- BS is the root of the build-sequence chain. FBS carries `bsId`, `buildOrder`, `executionStatus`, and `dependsOnFbsIds[]`.
+- TS carries `usId` and `acIds[]` (the ACs verified). TC lives inline in TS with per-TC `acId`.
+
+## Schema reference
+
+Per-schema docs in [`docs/`](./docs/README.md):
+
+- [common](./docs/common.md) | [prd](./docs/prd.md) | [req](./docs/req.md) | [user-story](./docs/user-story.md)
+- [tad](./docs/tad.md) | [tac](./docs/tac.md) | [adr](./docs/adr.md)
+- [build-sequence](./docs/build-sequence.md) | [fbs](./docs/fbs.md) | [test-suite](./docs/test-suite.md)
+- [manifest](./docs/manifest.md)
+
+Cross-cutting:
+
+- [id-conventions](./docs/id-conventions.md) - the `^<PREFIX>-\d{3,}$` pattern, prefix table, hierarchical AC ids.
+- [file-layout](./docs/file-layout.md) - recommended `rcf/` tree (not enforced).
+
+## What's deliberately NOT shipped
+
+The schemas repo is intentionally narrow:
+
+- **No validator CLI.** Pick the JSON Schema validator native to your language.
+- **No language-specific consumer SDKs or wrappers.**
+- **No cross-document reference validation.** That's traceability tooling (Phase 5 of `rcf-build-lite`).
+- **No status derivation from runtime evidence.** TS/TC pass/fail is runtime state, derived by traceability tooling.
+- **No file-layout enforcement.** Recommendations live in `docs/file-layout.md`; the schemas describe documents, not where they sit on disk.
+- **No SDD adapter.** The `rcf build <fbs-id>` markdown-assembly logic lives in `rcf-build-lite` (Phase 6 of that project), not here.
+
+## Versioning
+
+Pre-1.0 (0.x): breaking changes are signalled by a minor bump (`0.1.0` -> `0.2.0`) per semver 0.x convention. Patch bumps are additive only.
+
+Post-1.0: breaking changes require a documented migration path.
+
+See [CHANGELOG.md](./CHANGELOG.md).
+
+## License
+
+Apache 2.0, see [LICENSE](./LICENSE).

package/docs/README.md

@@ -0,0 +1,37 @@
+# RCF Schemas docs
+
+Per-schema reference + cross-cutting conventions for `@stravica-ai/rcf-schemas`.
+
+## Per-schema pages
+
+One page per schema file under `schemas/`.
+
+- [common](./common.md) - shared `$defs` referenced from every other schema.
+- [prd](./prd.md) - Product Requirements Document (shell).
+- [req](./req.md) - individual Requirement.
+- [user-story](./user-story.md) - User Story with inline Acceptance Criteria.
+- [tad](./tad.md) - master Technical Architecture Document.
+- [tac](./tac.md) - Technical Architecture Component.
+- [adr](./adr.md) - Architectural Decision Record.
+- [build-sequence](./build-sequence.md) - ordered FBS plan.
+- [fbs](./fbs.md) - Functional Build Specification.
+- [test-suite](./test-suite.md) - Test Suite for a single AC.
+- [manifest](./manifest.md) - project roots-only manifest.
+
+## Cross-cutting
+
+- [id-conventions](./id-conventions.md) - the `^<PREFIX>-\d{3,}$` pattern, prefix table, hierarchical AC ids, and the file/nested asymmetry.
+- [file-layout](./file-layout.md) - recommended `rcf/` tree, with TS files outside it (code-adjacent).
+
+## Out of scope (deliberately)
+
+What lives elsewhere:
+
+- No validator CLI ships from this repo. Use the JSON Schema validator native to your language.
+- No language-specific consumer SDKs or wrappers.
+- No cross-document reference validation (Phase 5 traceability tooling territory).
+- No status derivation from runtime test evidence (Phase 5 traceability).
+- No file-layout enforcement (the schemas describe documents, not where they sit on disk).
+- No SDD adapter (Phase 6 of `rcf-build-lite`).
+
+See the top-level [README](../README.md) for install and consumer-setup guidance across Node, Python, and Java.

package/docs/adr.md

@@ -0,0 +1,42 @@
+# adr.schema.json
+
+Architectural Decision Record. One per decision, one file each. Follows the Nygard convention (and MADR variant).
+
+## Canonical `$id`
+
+`https://schemas.stravica.io/rcf/v0.2.0/adr.schema.json`
+
+## Required fields
+
+| Field | Type | Notes |
+|---|---|---|
+| `adrId` | `^ADR-\d{3,}$` | This ADR's identifier. |
+| `prdId` | `^PRD-\d{3,}$` | Root PRD. |
+| `tadId` | `^TAD-\d{3,}$` | Parent TAD. |
+| `version` | semver | Per-document version. |
+| `status` | `adrStatus` enum: `draft`, `proposed`, `accepted`, `superseded`, `deprecated` | ADR-specific lifecycle. `draft` prepended in 0.2.0 for pre-proposal work-in-progress. |
+| `title` | string, min 1 | One-line decision title. |
+| `context` | string, min 1 | The situation that forced the decision. |
+| `decision` | string, min 1 | The decision itself. |
+| `consequences` | string, min 1 | What follows from it (positive and negative). |
+| `createdAt` / `updatedAt` | ISO 8601 date-time | Lifecycle timestamps. |
+
+## Optional fields
+
+| Field | Type | Purpose |
+|---|---|---|
+| `alternativesConsidered` | array of `alternative` | The MADR extension. |
+| `supersededBy` | `adrId` | When status is `superseded`, point at the ADR that replaced this. |
+| `relatedAdrs` | array of `adrId` | Cross-links between related decisions. |
+
+## Status enum (different from the authoring-status used by other docs)
+
+ADRs don't go through `draft -> review -> needsRevision -> approved`. They're optionally `draft` (pre-proposal notes), then `proposed`, then `accepted`, then potentially `superseded` (by a later decision) or `deprecated` (the area itself went away). This is intentional: the Nygard / MADR convention is widely understood and worth following.
+
+## Why ADRs are one file each
+
+Per-decision git history is the entire point. A decision evolves: it gets proposed, accepted, then years later superseded by a different decision. Squashing them into one big doc destroys that history and produces merge conflicts on every append. One file each: clean blame, clean supersession diff, append-friendly.
+
+## Example
+
+See `fixtures/valid/adr/adr-002-comprehensive.json` for a `superseded` ADR with alternatives considered and a `supersededBy` link.

package/docs/build-sequence.md

@@ -0,0 +1,44 @@
+# build-sequence.schema.json
+
+Build Sequence. One per project. Pure planning shell. FBS files each carry the mandatory `bsId` back-reference plus `buildOrder` and `executionStatus`. The walker computes the ordered FBS list by loading every FBS under `rcf/fbs/`, filtering by `bsId`, and sorting by `buildOrder`. Duplicate `buildOrder` values within one BS are a validation error at walker load time.
+
+## Canonical `$id`
+
+`https://schemas.stravica.io/rcf/v0.2.0/build-sequence.schema.json`
+
+## Required fields
+
+| Field | Type | Notes |
+|---|---|---|
+| `bsId` | `^BS-\d{3,}$` | This Build Sequence's identifier. |
+| `prdId` | `^PRD-\d{3,}$` | Root PRD. |
+| `version` | semver | Per-document version. |
+| `status` | `authoringStatus` enum | Lifecycle status of the sequence itself. |
+| `createdAt` / `updatedAt` | ISO 8601 date-time | Lifecycle timestamps. |
+
+## Optional top-level fields
+
+| Field | Type | Purpose |
+|---|---|---|
+| `title` | string | Human-readable title for the sequence. |
+| `buildPhilosophy` | string | One-paragraph "how we're going to attack this". |
+| `generationStrategy` | enum: `verticalSlice`, `dependencyFirst`, `domainGrouped`, `riskFrontLoaded` | The strategy used to order FBS items. |
+
+## Ordering and execution status
+
+Live on the FBS file, not on the BS. Each FBS carries:
+
+- `bsId` - parent BS.
+- `buildOrder` (integer >= 1) - position in the ordered sequence. Duplicates within one BS are a walker-time validation error.
+- `executionStatus` - `notStarted`, `inProgress`, `complete`, `verified`.
+- `dependsOnFbsIds[]` - other FBS ids this one depends on. Present on the derived (FBS) side; the walker inverts these into a dependents map at load time.
+
+**No `fbs[]` array on the BS.** Removed in 0.2.0. This eliminates the sync burden between the BS slot and the FBS file and makes drift impossible by construction.
+
+## Why this minimum-viable shape
+
+The BS exists to encode strategy and high-level context. Ordering, execution status, and dependencies live on the FBS file so that inserting, reordering, or deleting an FBS is a single-file edit. One source of truth, no drift risk.
+
+## Example
+
+See `fixtures/valid/build-sequence/bs-002-comprehensive.json` for a BS with a `verticalSlice` strategy. FBS ordering examples: `fixtures/valid/fbs/`.

package/docs/common.md

@@ -0,0 +1,43 @@
+# common.schema.json
+
+Shared `$defs` referenced via `$ref` from every other RCF schema. ID patterns, status enums, version string, timestamp format, and the `docRef` shape live here. This file is not itself a document schema; consumers register it alongside the other 10 schemas at validator init.
+
+## Canonical `$id`
+
+`https://schemas.stravica.io/rcf/v0.2.0/common.schema.json`
+
+## What's in `$defs`
+
+| Name | Shape | Used by |
+|---|---|---|
+| `prdId` | string, `^PRD-\d{3,}$` | every schema that references a PRD |
+| `reqId` | string, `^REQ-\d{3,}$` | `prd`, `req`, `user-story` |
+| `usId` | string, `^US-\d{3,}$` | `user-story`, `test-suite` |
+| `acId` | string, `^AC-\d{3,}(-\d+)?$` | `user-story.acceptanceCriteria[].id`, `fbs.acIds[]`, `test-suite.acId` |
+| `tadId` | string, `^TAD-\d{3,}$` | `tad`, `tac`, `adr` |
+| `tacId` | string, `^TAC-\d{3,}$` | `tac`, `fbs.contextRequirements.tacIds[]` |
+| `adrId` | string, `^ADR-\d{3,}$` | `adr`, `fbs.contextRequirements.adrIds[]` |
+| `bsId` | string, `^BS-\d{3,}$` | `build-sequence`, `fbs.bsId` |
+| `fbsId` | string, `^FBS-\d{3,}$` | `fbs.fbsId`, `fbs.dependsOnFbsIds[]` |
+| `tsId` | string, `^TS-\d{3}$` | `test-suite.id` |
+| `tcId` | string, `^TC-\d{3}-[a-z0-9-]+$` | `test-suite.testCases[].id` |
+| `version` | string, `^\d+\.\d+\.\d+$` | every doc-type schema |
+| `timestamp` | string, format `date-time` | every doc-type schema |
+| `authoringStatus` | enum: `draft`, `review`, `needsRevision`, `approved`, `superseded` | PRD, REQ, US, TAD, TAC, BS |
+| `adrStatus` | enum: `draft`, `proposed`, `accepted`, `superseded`, `deprecated` | ADR |
+| `executionStatus` | enum: `notStarted`, `inProgress`, `complete`, `verified` | FBS doc + BS slot |
+| `docRef` | object `{ id, path }` | manifest `prd`, `tad`, `bs` |
+
+## Why these are shared
+
+These types appear in many places and must stay identical. Inlining the patterns or enums in every schema would create a maintenance hazard, one edit becomes ten. The cross-file `$ref` setup eliminates that risk.
+
+The trade-off is that consumers register the schema bundle once at validator init rather than per document. See the [top-level README](../README.md) for the language-by-language registration recipe.
+
+## What's not here
+
+Per-doc-type enums (REQ `category`, REQ `priority`, FBS `riskLevel`, BS `generationStrategy`, etc.) stay local to their schema; they're not shared, so they don't earn a slot in `common`.
+
+## Version
+
+Carried on the `$id` URL path segment (`/v0.2.0/`). Bumps in lock-step with the bundle.