diff --git a/CHANGELOG.md b/CHANGELOG.md index bd87339..f360640 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -7,6 +7,20 @@ This project uses [Semantic Versioning](https://semver.org/). --- +## [0.4.1] — 2026-07-21 + +Draft patch (§6.3): clarifications only; no conformance requirements change. + +### Changed + +- **RFC-0001 §1.1** — Completed the *standard admission path* definition with the §3.4 loop-origin authorization step (clarification; no new requirement). +- **RFC-0001 §5.6** — Annotated the evidence-field list with per-event-type MUST pointers, including `principal_authorization` on loop-originated `memory_entry_admitted` events (cross-reference; no new requirement). +- **tests/conformance/negative/09-missing-memory/CASE.md** — Corrected the false claim that the validator reports missing `MEMORY.md` "as a warning only" (it is a violation since v0.2.0) and dropped the stale v0.2 anchor. +- **tests/conformance/positive/05-tier-rich-ward/CASE.md** — Reanchored the tier-name citation from "the v0.2 RFC frame" to RFC-0001 §5.3. +- **README.md, PRIMER.md, SPEC.md, rfcs/README.md, docs/faq.md, tests/conformance/README.md, validators/README.md, validators/validate.js, package.json** — Updated current-version references to v0.4.1. + +--- + ## [0.4.0] — 2026-07-19 ### Added diff --git a/PRIMER.md b/PRIMER.md index b740251..a49fcea 100644 --- a/PRIMER.md +++ b/PRIMER.md @@ -94,7 +94,7 @@ You do not need to use OpenCoven's infrastructure to implement familiar-contract ## Where to go next -- [`rfcs/RFC-0001-familiar-contract.md`](rfcs/RFC-0001-familiar-contract.md) — the normative specification (v0.4.0) +- [`rfcs/RFC-0001-familiar-contract.md`](rfcs/RFC-0001-familiar-contract.md) — the normative specification (v0.4.1) - [`examples/minimal/`](examples/minimal/) — the minimal structurally conformant familiar directory (Lumen) - [`examples/sage/`](examples/sage/) — a richer structurally conformant familiar directory (Sage) - `node validators/validate.js ./your-directory` — validate your claimant directory diff --git a/README.md b/README.md index 696723c..3aadf27 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ > **The Familiar Contract is an open specification for what an agent is allowed to be — not just what it can do, but what it cannot change about itself.** -[![specification: v0.4.0](https://img.shields.io/badge/specification-v0.4.0-8b5cf6)](rfcs/RFC-0001-familiar-contract.md) +[![specification: v0.4.1](https://img.shields.io/badge/specification-v0.4.1-8b5cf6)](rfcs/RFC-0001-familiar-contract.md) [![RFC-0001: Draft](https://img.shields.io/badge/RFC--0001-Draft-blue)](rfcs/RFC-0001-familiar-contract.md) [![license: MIT](https://img.shields.io/badge/license-MIT-green)](LICENSE) [![Ask DeepWiki](https://deepwiki.com/badge.svg)](https://deepwiki.com/OpenCoven/familiar-contract) @@ -40,11 +40,11 @@ These are not soft design preferences. Each one has architectural implications, ## How to Use This Spec **If you're building a familiar:** -1. Read [`rfcs/RFC-0001-familiar-contract.md`](rfcs/RFC-0001-familiar-contract.md) — the normative spec (v0.4.0) +1. Read [`rfcs/RFC-0001-familiar-contract.md`](rfcs/RFC-0001-familiar-contract.md) — the normative spec (v0.4.1) 2. Copy an example from [`examples/`](examples/) — `minimal/` for the floor, `sage/` for a richer structurally conformant familiar directory 3. Create `SOUL.md`, `IDENTITY.md`, `MEMORY.md`, and `ward.toml` for your familiar 4. Run `npm install` to install the reference validator's TOML parser and JSON Schema validator. -5. For a v0.4.0 structural-conformance claim, run both `node validators/validate.js ./your-directory` and `npm test` +5. For a v0.4.1 structural-conformance claim, run both `node validators/validate.js ./your-directory` and `npm test` **If you're evaluating a familiar:** - Five properties. All five. Fewer than five is an agent, not a familiar. @@ -62,10 +62,10 @@ These are not soft design preferences. Each one has architectural implications, # Install the reference validator dependencies npm install -# Validate the claimant directory for your v0.4.0 claim +# Validate the claimant directory for your v0.4.1 claim node validators/validate.js ./your-directory -# Verify the bundled reference validator + fixtures for the same v0.4.0 claim +# Verify the bundled reference validator + fixtures for the same v0.4.1 claim npm test ``` @@ -88,7 +88,7 @@ See [`validators/README.md`](validators/README.md) for full CLI docs. ## Repository Contents ``` -rfcs/RFC-0001-familiar-contract.md ← The Familiar Contract (normative, v0.4.0) +rfcs/RFC-0001-familiar-contract.md ← The Familiar Contract (normative, v0.4.1) README.md ← This file PRIMER.md ← Builder's guide (for new readers) CHANGELOG.md ← Version history diff --git a/SPEC.md b/SPEC.md index 1819bec..dd88a9d 100644 --- a/SPEC.md +++ b/SPEC.md @@ -2,7 +2,7 @@ > **Status:** Historical / superseded · **License:** MIT · **Version:** 0.1.0 > -> ⚠️ **This document is preserved for reproducibility.** The current normative specification is [RFC-0001 v0.4.0](rfcs/RFC-0001-familiar-contract.md), which uses RFC 2119 keywords (MUST/SHOULD/MAY), references the conformance suite at [`tests/conformance/`](tests/conformance/), and hardens the authority-layer separation requirement. +> ⚠️ **This document is preserved for reproducibility.** The current normative specification is [RFC-0001 v0.4.1](rfcs/RFC-0001-familiar-contract.md), which uses RFC 2119 keywords (MUST/SHOULD/MAY), references the conformance suite at [`tests/conformance/`](tests/conformance/), and hardens the authority-layer separation requirement. > > If you are looking for the current spec, go to [`rfcs/RFC-0001-familiar-contract.md`](rfcs/RFC-0001-familiar-contract.md). This file remains for historical and citation purposes. diff --git a/docs/faq.md b/docs/faq.md index b481a82..2c0a98f 100644 --- a/docs/faq.md +++ b/docs/faq.md @@ -12,7 +12,7 @@ The core problem it addresses is this: AI agents have gotten very capable, but t The specification has two major parts. First, a five-property identity contract: a compliant "familiar" must have a stable named identity, a declared purpose, enforced authority limits, persistent memory, and an explicit binding to a specific person. Second, an enforcement model built around a component called the Ward — a TOML policy document plus a runtime enforcement daemon that checks proposed changes against the protected surface before they are applied. The key word is "enforced": the Ward is not asking the agent to have good values about self-modification. It is an external check that runs regardless of what the agent thinks about it. -The Familiar Contract is a normative specification, which means it defines what must be true about a conformant system, tested against both a claimant-directory validator run and an executable conformance suite, not just described. The RFC (RFC-0001, v0.4.0) carries formal RFC 2119 keywords (MUST, MUST NOT, SHOULD) and the `tests/conformance/` directory is the fixture suite that verifies the reference validator. A familiar directory is structurally conformant only when `node validators/validate.js ./your-directory` succeeds and `bash tests/conformance/run-conformance.sh` passes in the repository. Full conformance also requires runtime Ward enforcement as described in RFC §6.2. +The Familiar Contract is a normative specification, which means it defines what must be true about a conformant system, tested against both a claimant-directory validator run and an executable conformance suite, not just described. The RFC (RFC-0001, v0.4.1) carries formal RFC 2119 keywords (MUST, MUST NOT, SHOULD) and the `tests/conformance/` directory is the fixture suite that verifies the reference validator. A familiar directory is structurally conformant only when `node validators/validate.js ./your-directory` succeeds and `bash tests/conformance/run-conformance.sh` passes in the repository. Full conformance also requires runtime Ward enforcement as described in RFC §6.2. --- @@ -278,7 +278,7 @@ The RFC also does not address security of the authority layer itself. If the War What you need is: a familiar directory with the required files (`SOUL.md`, `IDENTITY.md`, `MEMORY.md`, `ward.toml`); a `ward.toml` that conforms to the published schema; and an enforcement mechanism — a Ward authority daemon — that is structurally separate from the familiar's own logic. The reference implementation uses a Rust authority daemon (the `coven` layer), but the RFC is explicit that "other implementations may choose different mechanisms; what is normative is the separation, not the implementation." The structural conformance suite (`tests/conformance/`) has no Coven dependencies, but it does not by itself validate an arbitrary external directory. It verifies that the bundled reference validator accepts the positive fixtures and rejects the negative fixtures. Your own familiar directory still needs its own `node validators/validate.js ./your-directory` run. The reference validator requires Node.js plus `npm install`; its dependencies are a standards-compliant TOML parser and JSON Schema validator. The schemas (`schemas/`) are standard JSON Schema and can be validated with any conforming schema validator. -The parts of the spec that are Coven-specific — Doll proposals, Cave Board integration, multi-familiar routing — are referenced as context, not as requirements. A standalone familiar implementing a Ward daemon without any Coven infrastructure can be fully conformant with RFC-0001 v0.4.0. +The parts of the spec that are Coven-specific — Doll proposals, Cave Board integration, multi-familiar routing — are referenced as context, not as requirements. A standalone familiar implementing a Ward daemon without any Coven infrastructure can be fully conformant with RFC-0001 v0.4.1. --- @@ -292,6 +292,6 @@ If you want to understand how the Familiar Contract relates to other agent speci If you want to build a conformant familiar, start with `ward.toml` (conforming to `schemas/ward.schema.json`), create the required files, run `node validators/validate.js ./your-directory`, then run `bash tests/conformance/run-conformance.sh`, and iterate until both pass. The negative test cases tell you exactly what the validator checks for and why. -If you want to cite the specification in a paper, the canonical reference is RFC-0001 v0.4.0, available at `rfcs/RFC-0001-familiar-contract.md`. The accompanying paper (Alexander, 2026, forthcoming on arXiv) provides the academic framing including the principal-agent formulation, comparison with Self-Harness and SkillOpt, and formal definitions. The public companion authority-boundary design for Ward daemon builders is [OpenCoven/coven-threads `specs/PHASE-0-DESIGN.md`](https://github.com/OpenCoven/coven-threads/blob/main/specs/PHASE-0-DESIGN.md), but RFC-0001 §5 remains the normative Familiar Contract requirement. +If you want to cite the specification in a paper, the canonical reference is RFC-0001 v0.4.1, available at `rfcs/RFC-0001-familiar-contract.md`. The accompanying paper (Alexander, 2026, forthcoming on arXiv) provides the academic framing including the principal-agent formulation, comparison with Self-Harness and SkillOpt, and formal definitions. The public companion authority-boundary design for Ward daemon builders is [OpenCoven/coven-threads `specs/PHASE-0-DESIGN.md`](https://github.com/OpenCoven/coven-threads/blob/main/specs/PHASE-0-DESIGN.md), but RFC-0001 §5 remains the normative Familiar Contract requirement. If you have questions that are not answered here, open an issue in the repository. diff --git a/package-lock.json b/package-lock.json index 7f104f4..47402ab 100644 --- a/package-lock.json +++ b/package-lock.json @@ -1,12 +1,12 @@ { "name": "familiar-contract", - "version": "0.4.0", + "version": "0.4.1", "lockfileVersion": 3, "requires": true, "packages": { "": { "name": "familiar-contract", - "version": "0.4.0", + "version": "0.4.1", "dependencies": { "@iarna/toml": "2.2.5", "ajv": "8.20.0" diff --git a/package.json b/package.json index b863d25..f4bf533 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "familiar-contract", - "version": "0.4.0", + "version": "0.4.1", "private": true, "type": "commonjs", "scripts": { diff --git a/rfcs/README.md b/rfcs/README.md index ae60e46..94b5442 100644 --- a/rfcs/README.md +++ b/rfcs/README.md @@ -18,7 +18,7 @@ The RFC is the spec. The schemas are the machine-readable form. The conformance | Number | Title | Version | Status | Notes | |---|---|---|---|---| -| [RFC-0001](RFC-0001-familiar-contract.md) | The Familiar Contract | v0.4.0 | Draft | Canonical current draft | +| [RFC-0001](RFC-0001-familiar-contract.md) | The Familiar Contract | v0.4.1 | Draft | Canonical current draft | ## Historical snapshots @@ -56,14 +56,14 @@ Proposed → Draft → Review → Accepted → (Superseded) ## How to cite an RFC ``` -Familiar Contract RFC-0001 v0.4.0, "The Familiar Contract." +Familiar Contract RFC-0001 v0.4.1, "The Familiar Contract." OpenCoven, 2026. https://github.com/OpenCoven/familiar-contract/blob/main/rfcs/RFC-0001-familiar-contract.md ``` For academic citation, prefer the tagged release (the version tag is cut when the corresponding RFC revision merges; until then, cite the latest existing tag): ``` -https://github.com/OpenCoven/familiar-contract/releases/tag/v0.4.0 +https://github.com/OpenCoven/familiar-contract/releases/tag/v0.4.1 ``` ## License diff --git a/rfcs/RFC-0001-familiar-contract.md b/rfcs/RFC-0001-familiar-contract.md index daee038..6ba42e1 100644 --- a/rfcs/RFC-0001-familiar-contract.md +++ b/rfcs/RFC-0001-familiar-contract.md @@ -4,10 +4,10 @@ |---|---| | **Number** | RFC-0001 | | **Title** | The Familiar Contract | -| **Version** | 0.4.0 | +| **Version** | 0.4.1 | | **Status** | Draft | | **Authors** | Valentina Alexander, Sage | -| **Date** | 2026-07-19 | +| **Date** | 2026-07-21 | | **Supersedes** | SPEC.md v0.1.0 (in-tree predecessor; non-RFC form) | | **License** | MIT | | **Conformance** | `tests/conformance/` | @@ -20,7 +20,7 @@ This document defines the Familiar Contract: a normative specification for a cla The Familiar Contract addresses an architectural gap in current agent systems: the absence of a principled answer to the question *what is this agent not allowed to change about itself?* As recursive self-improvement loops (Self-Harness, Skill-Opt, sleep-time compute) become production-deployable, the absence of a protected surface is a design flaw, not an oversight. -This RFC is the formal, testable, citable specification. A familiar directory is structurally conformant with v0.4.0 only if `node validators/validate.js ` succeeds and `bash tests/conformance/run-conformance.sh` passes in this repository. +This RFC is the formal, testable, citable specification. A familiar directory is structurally conformant with v0.4.1 only if `node validators/validate.js ` succeeds and `bash tests/conformance/run-conformance.sh` passes in this repository. --- @@ -44,7 +44,7 @@ The following terms have specific meanings throughout this document: - **Authority layer** — The process, separate from the familiar, that enforces the Ward. The familiar MUST NOT be able to modify, restart, or reconfigure the authority layer (§5.1). - **Proposal** — A structured candidate change generated by a self-improvement loop, submitted for Ward-gated validation (§5.4). - **Continuity-bearing** — Describes a memory entry or memory surface whose content is carried forward across sessions as part of the familiar's persistent memory (§3.4). The contents of `MEMORY.md` are always continuity-bearing. An entry or surface whose continuity-bearing status cannot be determined MUST be treated as continuity-bearing. -- **Standard admission path** — The Ward-mediated path by which continuity-bearing entries are admitted into `MEMORY.md` or another continuity-bearing memory surface. The standard admission path validates source attestation, records the admission in the audit log, and rejects unverified continuity claims (§3.4, §5.6). +- **Standard admission path** — The Ward-mediated path by which continuity-bearing entries are admitted into `MEMORY.md` or another continuity-bearing memory surface. The standard admission path validates source attestation, verifies explicit human authorization for loop-originated entries (§3.4), records the admission in the audit log, and rejects unverified continuity claims (§3.4, §5.6). - **Approval tier** — The authority level required to promote a class of proposal (§5.3). - **Surface region identifier (`SurfaceRegionId`)** — A stable identifier declared in `editable.harness_blocks` naming one bounded region of the editable surface. Approval-tier `blocks` entries refer to surface regions only by these identifiers (§5.3.1). - **Deterministic extractor** — The runtime procedure that maps a `SurfaceRegionId` to the exact file paths or content regions it governs, producing the same result for the same committed Ward state every time it runs (§5.3.1). @@ -305,11 +305,11 @@ A Ward **SHOULD** define an append-only typed audit log. An implementation that - `event_type` (`proposal_submitted`, `proposal_approved`, `proposal_rejected`, `proposal_vetoed`, `ward_updated`, `memory_entry_admitted`, `principal_authorized_write`) - `proposal_id` when the event is proposal-related - `familiar_id` -- `ward_version`, `ward_hash` +- `ward_version`, `ward_hash` (MUST for `ward_updated` events — see below) - `tier`, `decision`, `approver` - `diff_hash`, `files_touched` -- `entry_hash` and `source_attestation` when `event_type = memory_entry_admitted` -- `principal_authorization` when `event_type = ward_updated` or `event_type = principal_authorized_write` +- `entry_hash` and `source_attestation` when `event_type = memory_entry_admitted` (MUST — see below) +- `principal_authorization` when `event_type = ward_updated` or `event_type = principal_authorized_write`, and when `event_type = memory_entry_admitted` for a loop-originated entry (MUST — see below) - Timestamps for submission, decision, promotion, admission, or authorization, as applicable A `memory_entry_admitted` event **MUST** include an `entry_hash` for the admitted memory entry and a `source_attestation` identifying the prior committed Ward state or principal-authorized write event that justifies admission. A `memory_entry_admitted` event for a loop-originated entry (§3.4) **MUST** additionally include the `principal_authorization` required by §3.4. A `principal_authorized_write` or `ward_updated` event **MUST** include `principal_authorization`, and a `ward_updated` event **MUST** additionally include `ward_version` and `ward_hash`; a source attestation that resolves to an event lacking these required fields **MUST** be treated as unverified. Source-attestation validation **MUST** confirm that the referenced committed Ward state or principal-authorized write event exists in the append-only audit log; an attestation whose referent cannot be resolved **MUST** be rejected. Audit log entries **MUST NOT** be deleted or modified. Append-only behavior is normative for any implementation claiming this section. @@ -320,14 +320,14 @@ A `memory_entry_admitted` event **MUST** include an `entry_hash` for the admitte ### 6.1 Conformance test suite -The directory `tests/conformance/` contains the executable reference conformance suite for this RFC. A claimant directory is **structurally conformant with v0.4.0** if and only if **BOTH** of the following are true: +The directory `tests/conformance/` contains the executable reference conformance suite for this RFC. A claimant directory is **structurally conformant with v0.4.1** if and only if **BOTH** of the following are true: - `node validators/validate.js ` succeeds for the claimant directory making the conformance claim. - `bash tests/conformance/run-conformance.sh` passes in this repository, demonstrating that the reference validator accepts every bundled positive fixture in `tests/conformance/positive/` and rejects every bundled negative fixture in `tests/conformance/negative/`. The claimant directory does **NOT** itself "pass the fixture suite"; the reference suite verifies the validator's behavior against bundled fixtures, while the claimant-directory run verifies the directory making the claim. Together they establish the structural claim only. They do **NOT** by themselves prove authority-layer separation, Gate 4 unbypassability, audit-log behavior, identity-probe consistency, or any other runtime requirement for full conformance. -A claim of v0.4.0 structural conformance **MUST** be backed by reproducible passing runs of both commands. +A claim of v0.4.1 structural conformance **MUST** be backed by reproducible passing runs of both commands. ### 6.2 Validator @@ -343,7 +343,7 @@ This RFC uses [Semantic Versioning](https://semver.org/) with an explicit draft - **Stable minor** (`x.y.0`, where `x >= 1` and `y > 0`): Backward-compatible normative additions and compatible schema evolution. - **Stable major** (`x.0.0`, where `x >= 1`): Backward-incompatible changes to existing conformance requirements or to the five properties. Requires a new RFC that supersedes this one. -A familiar claiming compliance with `v0.4.0` **MUST** satisfy the normative core as defined in this version. While this RFC remains `Draft`, clarifications and fixes that do not change conformance requirements **MUST** use a draft patch version bump; documented additive or breaking conformance changes **MUST** use a draft minor version bump. Once this RFC reaches `1.0.0` or higher, incompatible changes **MUST** use a major version bump; compatible additions **MUST** use a minor version bump; clarifications and fixes **MUST** use a patch version bump. +A familiar claiming compliance with `v0.4.1` **MUST** satisfy the normative core as defined in this version. While this RFC remains `Draft`, clarifications and fixes that do not change conformance requirements **MUST** use a draft patch version bump; documented additive or breaking conformance changes **MUST** use a draft minor version bump. Once this RFC reaches `1.0.0` or higher, incompatible changes **MUST** use a major version bump; compatible additions **MUST** use a minor version bump; clarifications and fixes **MUST** use a patch version bump. --- @@ -433,7 +433,7 @@ These gaps are intentional. The file-level conformance suite verifies the **stru - **`schemas/soul.schema.json`** — Required structural fields of `SOUL.md`. - **`schemas/identity.schema.json`** — Required structural fields of `IDENTITY.md`. - **`schemas/ward.schema.json`** — Required structural fields of `ward.toml`. -- **`tests/conformance/`** — Executable conformance suite for v0.4.0. +- **`tests/conformance/`** — Executable conformance suite for v0.4.1. ### 10.2 Informative @@ -453,6 +453,14 @@ These gaps are intentional. The file-level conformance suite verifies the **stru ## 11. Changelog +### v0.4.1 (2026-07-21) + +Draft patch per §6.3: clarifications only; no conformance requirements change. Both definitional items complete cross-references to obligations already present in the v0.3.0/v0.4.0 text. + +- Completed the §1.1 *standard admission path* definition with the loop-origin authorization step the path already performs under §3.4. +- Annotated the §5.6 evidence-field list with per-event-type MUST pointers to the paragraph that upgrades them, including `principal_authorization` on loop-originated `memory_entry_admitted` events. +- Corrected `tests/conformance/negative/09-missing-memory/CASE.md`, which falsely described missing `MEMORY.md` as "a warning only" (it is a violation since v0.2.0), and reanchored stale version references in conformance case docs. + ### v0.4.0 (2026-07-19) - Added a normative approval-tier compiler mapping from Ward TOML declarations to typed daemon approval paths and registered surface-region identifiers (§5.3.1). @@ -495,4 +503,4 @@ The original `SPEC.md` v0.1.0 — preserved for reproducibility. Superseded by t --- -*RFC-0001 — Draft v0.4.0 — 2026-07-19. Maintained at `OpenCoven/familiar-contract`.* +*RFC-0001 — Draft v0.4.1 — 2026-07-21. Maintained at `OpenCoven/familiar-contract`.* diff --git a/tests/conformance/README.md b/tests/conformance/README.md index acb33d7..8c945c8 100644 --- a/tests/conformance/README.md +++ b/tests/conformance/README.md @@ -1,4 +1,4 @@ -# Familiar Contract v0.4 Conformance Suite +# Familiar Contract v0.4.1 Conformance Suite This directory is the testable form of the Familiar Contract: a set of fixture familiars that verify the reference validator against the bundled positive and negative cases for the current RFC-0001 draft. It does not validate a claimant directory by itself. @@ -11,4 +11,4 @@ npm test Convention: `positive/-/` cases should PASS when run with `node validators/validate.js `. `negative/-/` cases should FAIL for the documented reason in that case's `CASE.md`. Structural conformance for a claimant directory additionally requires `node validators/validate.js ` and `npm test`. -A claim of v0.4.0 structural conformance = the claimant directory passes `node validators/validate.js ` and this fixture suite passes under `npm test`. +A claim of v0.4.1 structural conformance = the claimant directory passes `node validators/validate.js ` and this fixture suite passes under `npm test`. diff --git a/tests/conformance/negative/09-missing-memory/CASE.md b/tests/conformance/negative/09-missing-memory/CASE.md index 9e50b0e..22247aa 100644 --- a/tests/conformance/negative/09-missing-memory/CASE.md +++ b/tests/conformance/negative/09-missing-memory/CASE.md @@ -1,3 +1,3 @@ # 09 Missing MEMORY.md -Violated property: Persistent Memory. Validator check: `checkMemory` should reject this because `MEMORY.md` is absent, but the current implementation reports it as a warning only. Expected behavior for v0.2 conformance: `node validators/validate.js ` exits non-zero with an error pattern like `MEMORY.md does not exist`. +Violated property: Persistent Memory. Validator check: `checkMemory` rejects this because `MEMORY.md` is absent — RFC-0001 §3.4 requires `MEMORY.md` to exist (it MAY be empty or a bootstrap stub) so it can be a member of `[protected].files`. Expected behavior: `node validators/validate.js ` exits non-zero with an error pattern like `MEMORY.md does not exist`. diff --git a/tests/conformance/positive/05-tier-rich-ward/CASE.md b/tests/conformance/positive/05-tier-rich-ward/CASE.md index 6ea74ac..f15aedd 100644 --- a/tests/conformance/positive/05-tier-rich-ward/CASE.md +++ b/tests/conformance/positive/05-tier-rich-ward/CASE.md @@ -1,3 +1,3 @@ # 05 Tier Rich Ward -This case demonstrates a Ward that declares all four approval tiers named by the v0.2 RFC frame: `auto`, `familiar_review`, `human_review`, and `human_required`, while preserving the required protected, editable, and human-belonging declarations. +This case demonstrates a Ward that declares all four approval tiers named by RFC-0001 §5.3: `auto`, `familiar_review`, `human_review`, and `human_required`, while preserving the required protected, editable, and human-belonging declarations. diff --git a/validators/README.md b/validators/README.md index 37d4dcb..bb7e30b 100644 --- a/validators/README.md +++ b/validators/README.md @@ -1,6 +1,6 @@ # Validator — familiar-contract -A Node.js CLI that checks one claimant directory for the familiar-contract v0.4.0 structural requirements. It parses `ward.toml` with `@iarna/toml` and validates the resulting object against `schemas/ward.schema.json` with Ajv before evaluating Ward semantics. +A Node.js CLI that checks one claimant directory for the familiar-contract v0.4.1 structural requirements. It parses `ward.toml` with `@iarna/toml` and validates the resulting object against `schemas/ward.schema.json` with Ajv before evaluating Ward semantics. ## Requirements @@ -45,7 +45,7 @@ node validators/validate.js --help ## Output ``` -familiar-contract validator v0.4.0 +familiar-contract validator v0.4.1 Checking: /path/to/familiar Property Coverage: @@ -76,7 +76,7 @@ There are no warnings for missing required files; `MEMORY.md` absence is a failu - Whether the Ward is actually enforced at runtime (that requires a Ward daemon) - Whether the familiar's behavior matches its declared purpose (behavioral compliance requires runtime evaluation) -This validator checks whether one claimant directory satisfies the required file-level declarations for v0.4.0. That claimant-directory run is necessary, but not sufficient, for a structural-conformance claim: you must also run `bash tests/conformance/run-conformance.sh` so the bundled reference validator is shown to accept the positive fixtures and reject the negative fixtures for the same contract version. Full conformance additionally requires runtime Ward enforcement beyond this file-level check, and missing `MEMORY.md` is a violation, not a warning. +This validator checks whether one claimant directory satisfies the required file-level declarations for v0.4.1. That claimant-directory run is necessary, but not sufficient, for a structural-conformance claim: you must also run `bash tests/conformance/run-conformance.sh` so the bundled reference validator is shown to accept the positive fixtures and reject the negative fixtures for the same contract version. Full conformance additionally requires runtime Ward enforcement beyond this file-level check, and missing `MEMORY.md` is a violation, not a warning. ## For CI Integration @@ -89,4 +89,4 @@ This validator checks whether one claimant directory satisfies the required file run: npm test ``` -Both steps must pass for a reproducible v0.4.0 structural-conformance claim. The first checks the claimant directory; the second verifies the bundled reference validator and fixtures. Exit code 1 on either step will fail CI. +Both steps must pass for a reproducible v0.4.1 structural-conformance claim. The first checks the claimant directory; the second verifies the bundled reference validator and fixtures. Exit code 1 on either step will fail CI. diff --git a/validators/validate.js b/validators/validate.js index b8470fe..98f3662 100755 --- a/validators/validate.js +++ b/validators/validate.js @@ -405,7 +405,7 @@ ${bold('Exit codes:')} process.exit(1); } - console.log(`\n${bold('familiar-contract validator')} ${dim('v0.4.0')}`); + console.log(`\n${bold('familiar-contract validator')} ${dim('v0.4.1')}`); console.log(dim(`Checking: ${dirPath}\n`)); const allViolations = [];