Skip to content

docs: correct claim that RFC-0001 specifies Doll origin.doll_id - #16

Open
BunsDev wants to merge 1 commit into
mainfrom
docs/doll-rfc-claim
Open

docs: correct claim that RFC-0001 specifies Doll origin.doll_id#16
BunsDev wants to merge 1 commit into
mainfrom
docs/doll-rfc-claim

Conversation

@BunsDev

@BunsDev BunsDev commented Aug 9, 2026

Copy link
Copy Markdown
Member

Fixes the claim in docs/ward-deep-dive.md that RFC-0001 specifies Doll proposals with origin.doll_id. It does not. Full evidence is in #15.

The problem

docs/ward-deep-dive.md L371 read:

The RFC mentions Doll proposals (from cloud/mobile instances of a familiar) with origin.doll_id, and notes that Doll proposals cannot be Tier 0 auto-promoted into a true familiar.

Both clauses attribute content to the RFC that is not in it.

Verification

doll (case-insensitive) occurrence counts across every normative file in this repo, checked at f1da013:

File Lines doll
rfcs/RFC-0001-familiar-contract.md (v0.7.0, current) 584 0
rfcs/RFC-0001-familiar-contract-v0.2.md 430 0
rfcs/RFC-0001-familiar-contract-v0.3.md 458 0
rfcs/RFC-0001-familiar-contract-v0.4.md 506 0
rfcs/RFC-0001-familiar-contract-v0.5.md 528 0
rfcs/RFC-0001-familiar-contract-v0.6.md 567 0
SPEC.md 0

The unversioned RFC-0001-familiar-contract.md carries Version | 0.7.0 in its header and CHANGELOG.md's newest entry is [0.7.0], so the zero-doll file is the current normative text. There is no v0.7.md in rfcs/.

What changed

docs/ward-deep-dive.md — rewritten to describe Doll semantics as a Coven architectural concept and future work rather than existing RFC content. The phrasing deliberately matches the sibling "Multi-familiar proposal interactions" section three paragraphs above, which already says "The current RFC does not specify..." — so this is the file's own house style, not a new convention. The section's closing sentence (already calling this "future work") is unchanged and now agrees with its opening.

docs/faq.md L149 — a softer case. It described proposal structure with origin.doll_id in a way that reads as spec-derived. Hedged to attribute it to the Coven architecture and note it is not yet specified in the RFC. Happy to drop this hunk if you consider it in-scope as-is.

Deliberately NOT changed

These are accurate and I would argue against touching them:

  • docs/faq.md L281"The parts of the spec that are Coven-specific — Doll proposals, Cave Board integration, multi-familiar routing — are referenced as context, not as requirements." This is the best statement of Doll's true status anywhere in the repo.
  • docs/faq.md L155 — already scoped with "in the Coven architecture".
  • docs/ward-primer.md L133 and CHANGELOG.md L224 — both correctly list Doll as future work.

Why it's worth fixing

This one sentence propagated. It was cited downstream in coven-grimoire's Ward Layer Spec Brief as "RFC-0001 v0.2.0 ... Doll origin.doll_id" (v0.2 has zero occurrences), and from there into a design doc in coven-threads — three repos deep from a single line. Downstream work was close to pinning the field spelling origin.doll_id as though it were normative.

Validation

npm test
  positive: 7/7 passed
  negative: 38/38 failed correctly
  audit-records: READY

Docs-only; no schema or normative text touched.

Note: node -e "... readdirSync('schemas') ... JSON.parse" from AGENTS.md fails on main as well — schemas/ contains coven-memory-schema.md, which isn't JSON. Pre-existing and unrelated; all five .json schemas parse. Worth a follow-up to filter by extension.

Closes #15


🪞 Found and filed by Echo while scoping coven↔coven handoffs in coven-threads. Reported as an issue first rather than pushed directly; opening the PR at Val's direction. Not self-merging — this is a spec repo and the wording is yours to ratify.

`docs/ward-deep-dive.md` stated that the RFC "mentions Doll proposals ...
with `origin.doll_id`" and "notes that Doll proposals cannot be Tier 0
auto-promoted". Neither clause appears in any normative text.

Verified `doll` has zero occurrences in RFC-0001-familiar-contract.md
(v0.7.0, the current normative text), rfcs v0.2-v0.6, and SPEC.md.

Rewrites the two prose lines that attribute Doll semantics to the RFC so
they describe it as a Coven architectural concept and future work, matching
the phrasing already used by the sibling "Multi-familiar proposal
interactions" section ("The current RFC does not specify ...").

Deliberately unchanged, because they are already accurate:
- docs/faq.md L155 and L281 (L281 states Doll proposals are "referenced as
  context, not as requirements")
- docs/ward-primer.md L133 and CHANGELOG.md L224 (both list Doll as future work)

Docs-only; no schema or normative text touched. `npm test` passes
(7/7 positive, 38/38 negative, audit-records READY).

Closes #15

Signed-off-by: Val Alexander <bunsthedev@gmail.com>

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR corrects documentation that incorrectly attributed “Doll proposal” semantics (including origin.doll_id and Tier 0 auto-promotion constraints) to RFC-0001, clarifying that these are Coven-architecture concepts not yet specified in normative text.

Changes:

  • Rewrites the “Doll proposal semantics” section in docs/ward-deep-dive.md to explicitly state the RFC does not specify Dolls and that the described semantics are future work.
  • Hedges proposal-structure wording in docs/faq.md to avoid implying origin.doll_id is RFC-specified, while still describing it as a Coven-architecture concept.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
docs/ward-deep-dive.md Removes the incorrect claim that RFC-0001 specifies Doll proposals and reframes Doll semantics as non-normative/future work.
docs/faq.md Adjusts proposal-structure wording to clearly separate Coven-architecture concepts (e.g., origin.doll_id) from RFC-specified requirements.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

docs: ward-deep-dive L371 claims the RFC specifies Doll origin.doll_id; no RFC version contains it

2 participants