Skip to content

weaver doctor and setup refusals - #4

Closed
MrPickering wants to merge 1 commit into
agent/weaver-s0-identityfrom
agent/weaver-s1-doctor
Closed

MrPickering wants to merge 1 commit into
agent/weaver-s0-identityfrom
agent/weaver-s1-doctor

Conversation

@MrPickering

Copy link
Copy Markdown
Contributor

Stacked on #3. Merge #3 first, then retarget this PR to main.

Why

A pipeline that travels as one zip holding both the tool and the book, edited by chat-only AIs, can't work: every session can change the tool, and nothing tells a modified tool from the released one. Weaver should refuse to run in that setup and explain why in plain words. Firm on setup, flexible on story.

What

  • weaver doctor [--root] [--json] checks Node >= 22, Git available, book under Git, tool and book in separate folders (including a copied engine inside the book), install integrity, and a note that a command-running AI host is required.
  • Refusals: state:accept, release and grounding --output stop and write nothing when anything is blocking, with a plain-words problem, why and fix. Read-only commands warn on stderr and still run. No flag or environment variable bypasses a refusal.
  • weaver init runs git init in new books.
  • integrity.json: a committed, lockfile-style sha256 manifest of the published package, with CRLF normalised so every platform agrees. npm test fails when it's stale; run npm run integrity after changing package files.

Verification

  • npm run preflight: 19/19 tests, leakscan, smoke, consumer install
  • Every blocking check has a known-bad test. The consumer test tampers with a file in the installed copy from the packed tarball: doctor reports modified and release refuses.
  • Manual: a book outside Git and a copied engine inside a book both refuse with a readable message. Frozen release and state schemas are unchanged.

🤖 Generated with Claude Code

A book pipeline that travels as one zip holding both the tool and the
book, edited by chat-only AIs, cannot work: every session can change the
tool, and nothing can tell a modified tool from the released one. Weaver
now checks its setup and refuses, in plain words, to write into a book
when that setup is unsafe.

- `weaver doctor [--root] [--json]` reports: Node >= 22, Git available,
  book under Git, tool and book in separate folders (including a copied
  Weaver engine inside the book), install integrity, and a note that a
  command-running AI host is required.
- state:accept, release and `grounding --output` refuse when anything is
  blocking and write nothing. Read-only commands still run and warn on
  stderr. No flag or environment variable bypasses a refusal.
- `weaver init` runs `git init` in new books.
- integrity.json: a committed, lockfile-style sha256 manifest of the
  published package, hashed with CRLF normalised to LF so Windows, Linux
  and npm installs agree. `npm test` fails when it is stale.
- Tests prove each blocking check can fail, including tampering with an
  installed copy from the packed tarball (doctor reports `modified`,
  release refuses).

Verified: npm run preflight (19/19, leakscan, smoke, consumer install
with tamper break-test); manual refusals for a book outside Git and a
copied engine inside a book.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Session-Id: 04db4d93-9884-44ee-b28f-627e92b33731
Agent: claude-code
@MrPickering

Copy link
Copy Markdown
Contributor Author

Landed on main via #9 (merge of the full stack).

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.

1 participant