# Memeroot working directory

> This file is `~/memeroot-work/CLAUDE.md`. Claude Code reads it at session start.
> It tells Claude Code about the workflow, the available tools, and the conventions.
> Update it as you change directory layout or add tools.

---

## What this directory is for

Producing **transferable, cryptographically signed knowledge artifacts** using the Memeroot platform — primarily regulated audit packets (SOX, FDA, IRB), captured-hash evidence, and pitch documents. The artifacts produced here are signed in the Memeroot canvas and shipped to external parties (auditors, regulators, prospects) who can verify them locally in any browser.

This is the **using** environment, not the platform-building environment. The platform itself (canvas, skill packs, CLI, builders) lives in a separate Claude Project. Here we use what's already built.

## Skills available

Two production skill packs are installed in `~/.claude/skills/`:

**`regulated-document-author`** — invoke when producing regulated documentation:
- SOX 404 / ICFR controls (TOD, TOE, findings, management letters)
- FDA 21 CFR Part 11 records
- IRB protocols (ICH GCP E6(R3) + 45 CFR 46)
- HIPAA documentation, DFARS, GAMP 5
- Triggers: "SOX control", "ICFR", "FDA 21 CFR Part 11", "IRB protocol", "audit packet", "test of design", "TOE", "management letter", etc.

**`memeroot-bridge`** — invoke when producing output for the Memeroot canvas:
- XML regions with stable IDs
- Known kinds: `<note>`, `<section>`, `<decision>`, `<task>`, `<reference>`, `<iframe-region>`, `<workspace>`
- Composes with regulated-document-author (and any future domain skills)
- Triggers: "Memeroot region", "canvas region", "addressable region", "signed region", "workspace bundle"

When both skills activate together (e.g. "document the REV-001 control as a Memeroot packet"), the bridge skill provides XML structure and the domain skill provides field content.

## Tools available

In `tools/`:

- **`MR-CANVAS-v0.8.html`** — the substrate canvas. Open in a browser to drop region files, build tree, sign regions, export bundles.
- **`iframe-region-builder.html`** — author iframe-regions with captured-hash snapshot capture. Live form + preview + SHA-256 + sandbox toggles. Three presets.
- **`memeroot-bridge-bundle.html`** — viewer for the bridge skill pack contents (templates, examples, composition pattern).
- **`regulated-document-author-bundle.html`** — viewer for the regulated-document-author skill pack contents.
- **`memeroot-catalog.html`** — full catalog of Memeroot components for reference.

In `~/.local/bin/memeroot` (or wherever npm globals live):

- **`memeroot validate <files>`** — checks well-formedness, stable IDs, no fake signatures, no absolute paths, no unfilled `[NEEDS INPUT:...]` placeholders. **Also verifies `<captured-hash>` matches `<snapshot>` CDATA SHA-256 when both present.**
- **`memeroot bundle <files> -o workspace.xml`** — combines region files into one workspace.
- **`memeroot package <files> -o packet.html`** — produces canvas-ready HTML with regions pre-loaded.

## Directory layout

```
~/memeroot-work/
├── CLAUDE.md              ← this file
├── tools/                  canvas + builders + bundle viewers
├── packets/                audit packets you produce, organized by scope
│   ├── 2026-Q1/
│   │   └── REV-001/
│   │       ├── control.xml          ← Claude Code writes these
│   │       ├── tod.xml
│   │       ├── toe.xml
│   │       └── audit-packet.html    ← memeroot package outputs this
│   └── ...
├── snapshots/              captured-hash HTML evidence
├── identities/             public keys / identity refs (NEVER private keys — those stay in the canvas)
└── outputs/                general work outputs (pitches, drafts, notes)
```

When producing audit packets, default to `packets/<period>/<control-id>/`. Use period codes (2026-Q1, 2026-Q2, etc.) and the canonical control ID. Keep all region files for one control in one directory; that's also where the packaged HTML goes.

## Standard workflows

### Workflow 1: Produce a SOX audit packet

User says: *"Document REV-001 revenue cutoff control for SOX Q1 2026 as a Memeroot packet."*

1. Create `packets/2026-Q1/REV-001/` if it doesn't exist
2. With **regulated-document-author + memeroot-bridge** skills active, produce:
   - `control.xml` — the `<control>` region with all SOX fields filled
   - `tod.xml` — `<test-of-design>` template stub (or fully filled if user provided the audit details)
   - `toe.xml` — `<test-of-operating-effectiveness>` template stub
3. Validate: `memeroot validate packets/2026-Q1/REV-001/*.xml`
4. If anything fails validation, fix it before continuing
5. Package: `memeroot package packets/2026-Q1/REV-001/*.xml -o packets/2026-Q1/REV-001/audit-packet.html --title "REV-001 Q1 2026 audit packet"`
6. Tell the user: open `packets/2026-Q1/REV-001/audit-packet.html` in a browser; canvas will boot with three regions in the Tree, ready for signing.

### Workflow 2: Capture a snapshot as evidence

User says: *"Capture the current revenue dashboard at https://bi.example.com/revenue/q1-2026 as audit evidence."*

Don't try to fetch via the bash tool — CORS and auth will get in the way. Instead:

1. Tell the user to:
   a. Open `tools/iframe-region-builder.html` in a browser
   b. Paste the URL into the form
   c. Click "Capture from URL" (or paste the HTML manually if CORS blocks)
   d. Verify the hash auto-computed
   e. Click "Download .xml" — gets `EMBED-DASHBOARD-Q1-2026.xml`
2. Move the downloaded XML into `snapshots/2026-04-05/` or wherever it belongs
3. Run `memeroot validate <file>` — should report "snapshot 2247b · sha256 verified"
4. To include the snapshot in an existing packet, re-run `memeroot package` with the snapshot file added to the list

### Workflow 3: Iterate on a regulated document

User says: *"The CFO wants the REV-001 description to mention quarterly reconciliation explicitly. Update it."*

1. Edit `packets/2026-Q1/REV-001/control.xml` directly (use the existing file as basis, don't regenerate from scratch)
2. The control had a stable id (`REV-001`). Don't change the id; the change is a content edit, not a fork.
3. Re-validate and re-package.
4. Tell the user: the audit-packet.html is regenerated. If they had already signed the previous version in the canvas, the new packet needs to be re-signed (signatures bind to specific content bytes).

### Workflow 4: Fork a control for a new period or scope

User says: *"REV-001 changed in Q3 — the threshold went from $10K to $25K. Fork it."*

1. Create `packets/2026-Q3/REV-001-v2/` 
2. Copy the Q1 control.xml as a starting point
3. Change the id to `REV-001-v2` or `REV-001-2026Q3`
4. Add a `<fork-source>` element referencing the original: `<fork-source id="REV-001" version="1"/>` 
5. Add an `<amendment-note>` describing what changed and why
6. Sign the new fork separately. **Don't overwrite the original Q1 control.xml — that breaks audit trail.**

## Communication style

- **Terse.** Lead with the deliverable. No process narration.
- **No closing pleasantries.** No "let me know if..." / "feel free to..."
- **No fabricated values.** If a field needs information you don't have, leave it as `[NEEDS INPUT: <description of what's needed>]`. Auditors recognize boilerplate.
- **No fake signatures.** Never generate `<signature value="..."/>` elements with made-up base64. Real signatures come from the canvas signing feature at signing time.
- **One clarifying question max** before proceeding. If genuinely ambiguous, ask one thing; otherwise pick the most useful interpretation and ship.

## Validation gates

Before declaring any audit packet ready:

1. **`memeroot validate`** passes for all region files with no errors and zero `[NEEDS INPUT:...]` warnings (or only intentionally-unfilled ones the user has acknowledged)
2. **Each XML file** has a stable id matching `[A-Za-z][A-Za-z0-9_-]{1,127}`
3. **No fake signatures** anywhere in the output
4. **No absolute filesystem paths** in `<ref>` or any href/path/src attributes
5. **iframe-region snapshots** (if any) verify their captured-hash

If validation fails, fix the file and re-run. Don't ship work that didn't pass.

## Don't

- **Don't sign anything programmatically.** Signing is a wet-signature analog — it requires a real human at the canvas with their identity. Producing signed XML from a script is the structural equivalent of forging a signature. The skills and CLI are designed to produce content that is *signable* but not yet signed.
- **Don't store private keys in this directory.** Identities live in the canvas (browser keystore via WebCrypto). The `identities/` folder is for public references only — emails, roles, descriptive notes.
- **Don't bypass the canvas for signing.** Even if the user asks "just sign it for me," the answer is: produce the content, open the packet, sign in the Sign tab. The audit trail value of separation of duties depends on it being real separation.
- **Don't regenerate files that already exist** unless explicitly asked. If `control.xml` is there and the user asks for a TOE, write `toe.xml`; don't touch the existing control.

## Reference

- Skill pack viewers: `tools/regulated-document-author-bundle.html` and `tools/memeroot-bridge-bundle.html` — open in browser to see all templates and examples
- Full Memeroot catalog: `tools/memeroot-catalog.html` — shows everything available in the Memeroot ecosystem
- Live builder for iframe-regions: `tools/iframe-region-builder.html`
