Version. 0.13
Date. 2026-08-03
Charter. standing-notes/dunin7-standing-authorization-charter-v0_1.
Author. Claude Code (verification session). Operator: Marvin Percival.
Supersedes. v0.12 at record 85eb049. All earlier versions stand as siblings; v0.3 remains deliberately absent.
Changes from v0.12. The outstanding download verification is done. A produced render was seeded directly, and the route was exercised as the surface calls it. All four questions answered; nothing was spent. CR-2026-162's acceptance gate is now complete except for one item that remains fenced.
A render can be seeded without the composition pipeline, so nothing halted.
The substrate stores a render in two places: the memory_events payload, and the render_events_view projection that get_render_event reads current_version from. Rather than hand-writing either, the seed went through the engine's own append_event with a real RenderEvent object — so the payload is whatever the model produces and the projector wrote the view row itself. The pipeline was bypassed; the substrate was not.
Projection confirmed before any request: state=produced, render_format=HTML, display_number=1.
Fences. Throwaway cr162_dl, cloned from playground_test and dropped at teardown. Engine on spare port 8097, torn down, port free. .env never modified — the database URL and secret were inline. playground_dev never connected to; the live :8000 process is the same PID. No code, no commits — both repos clean at ffc29af and 50252e1.
Status and content type. GET …/renders/{id}/download → 200, Content-Type: text/html; charset=utf-8, 3,359 bytes.
Filename. attachment; filename="html--personal-marvin--2026-08-03.html" — composed by the engine from format, engagement and date. This is the value the adapter reads off Content-Disposition rather than inventing, and the design decision holds: no surface-side guess would have produced it.
Do the bytes match the seed? Not byte-for-byte, and that is correct. The route materializes rather than passes through: 59 bytes of seeded content came back as a 3,359-byte HTML document with doctype, head, title and styles. The seeded content survives exactly — the fragment <h1>Care guide</h1><p>Goosey needs feeding twice a day.</p> appears verbatim in the output, once.
> The expectation needed correcting, not the code. "Bytes received match bytes seeded" is the wrong test for a materializing route. The right one is that the seeded content survives materialization intact, and it does.
Does the format override behave as its contract was read to say? Yes, precisely.
| Request | Result |
|---|---|
| no override (declared HTML) | 200, text/html, .html filename, wrapped document |
| ?format=MD | 200, text/markdown; charset=utf-8, .md filename, 59 bytes — the seeded content unwrapped |
| ?format=DOCX | 422, unsupported_render_format, listing HTML, HTML_DOCUMENT, MARKDOWN, MD, PDF, PLAIN_TEXT |
The contract read at Step 0 said the override grabs an alternative copy without producing a second render, and that a bad format yields 422 carrying the supported list so the caller can recover. Both hold exactly. The same stored render served two formats and two filenames, and the engine wrote nothing new.
B-7's download half is now verified end to end — seeded render, real engine, real route, real bytes, on the auth path the surface uses.
One item remains unverified: the discovery skill's own round trip. It requires an external LLM call, and the instruction was not to spend. The schema boundary that was the defect is proven fixed (v0.12: POST 201 and GET 200 both carrying source_mode: "discovery"); what is unexercised is the extraction upstream of it. Named, not claimed.
B-35 stands — DiscoveryToSeedNotConfiguredError returns 500 where its siblings return 503.
CR-2026-162's gate is met, with the single exception above. Gate item 6 — "a download of a finished render succeeds through the engine's existing route" — is now verified directly rather than by component test.
F-1 unchanged: five merges await one restart.
DUNIN7 — Done In Seven LLC — Miami, Florida DUNIN7 — status brief — v0.13 — 2026-08-03 One render, two formats, two filenames, and nothing produced twice.