Version. 0.12
Date. 2026-07-17
Author. Claude.ai, on Operator direction.
Target. /Users/dunin7/loomworks-marketing. Cloudflare Pages project. New chain under functions/api/sales/; new Astro page. The existing Example Generator is not touched.
Technical consumer. Claude Code on DUNIN7-M4.
Status. Build specification for a disposable spike. Filed as CR-2026-152 — confirmed next-free against the record's highest existing numbered CR (CR-2026-151, change-requests/cr-2026-151-dismiss-not-recognized-v0_1.md) at filing time (2026-07-16).
Companion to. Example Generator CR v0.2 (D1–D8, the public generator), scoping note v0.3, sales-perspective mockup v0_2.
Change from v0.1. Section 8 (Access) only. The Operator settled the access decision v0.1 left open: the spike sits behind Cloudflare Access from the first deploy, reachable from the web, not local-only. Section 8 is replaced entirely — the Access application's scope (page + API routes, no wider), the dashboard-only-configuration limitation, and the Operator-owns-policy-membership boundary are now specified. No other section changes. (v0.1 is kept byte-intact as the superseded prior.)
Change from v0.2. Section 4.2 only. The step-3 fabrication audit (2026-07-16, perishables input) disproved this section's completeness claim: the check panel was stated to be "complete by construction," and two rendered specifics with no corresponding finding — found in the systems-lead column on the same run that produced a clean owner column — show it is not. Section 4.2 is replaced entirely: the check panel is still filtered from source, still computed not generated, but the completeness claim is retracted and the panel's real scope (complete with respect to findings, not with respect to prose) is stated instead, with the audit's two quoted specifics as evidence. The prior, now-corrected claim is preserved below the correction rather than deleted. No other section changes. (v0.2 is kept byte-intact as the superseded prior.)
Change from v0.3. Section 10 only. Acceptance criterion 4 still carried the completeness claim that section 4.2 retired in v0.3; corrected. This was specified during the v0.3 amendment and did not land. No other section changes. (v0.3 is kept byte-intact as the superseded prior.)
Change from v0.4. Sections 3.1, 3.2, and 5. The four reader archetypes (owner, ops lead, food safety/audit, systems lead) were perishables-specific and hardcoded; an Operator test on legal work produced columns shaped for readers that did not exist in that scenario. Readers are now derived from the work: analyze's output gains a readers array (§3.1), and the page becomes two-phase — an empty, generic ask; then, only after analyze returns, a reader section populated from what it proposed (§5). §3.2's example carried a hardcoded perishables reader ("reader": "owner", a margin-and-dock-level rationale) and was made reader-agnostic — the only concrete shape example in the CR, and a build session reads examples as intent. No other section changes. (v0.4 is kept byte-intact as the superseded prior.)
Change from v0.5. Section 3.1 only. v0.5 introduced derived readers but said only "readers" without specifying which kind — the legal test that followed derived readers of the prospect's own work product (lead trial counsel, litigation paralegal, testifying expert) rather than readers of the sales material itself. The tool produced feature illustrations of how the prospect's work would be shaped, not pitches for the prospect to buy the tool — collapsing this spike into what the public Example Generator already does. Section 3.1 now specifies which readers are meant, immediately after the readers array structure: decision-makers and influencers at the prospect organization, not roles inside the prospect's own work; observations about the prospect's own work-product readers belong in findings, not readers. Prompt posture is rewritten accordingly. Follow-on for next build, not done here: §5's reader-section subtitle was written before this correction and will need a matching update — noted, not edited, since this amendment is scoped to §3.1 only. No other section changes. (v0.5 is kept byte-intact as the superseded prior.)
Change from v0.6. Section 4.1 only. The contrast definition intersected foregrounded with cut, which reported no contrast on pairs differing on a third of the findings — measured on two real pairs, 0 narrow against 5 broad, and 1 narrow against 9 broad. The computation was correct; the definition was too narrow. Corrected to report both tiers. No other section changes. (v0.6 is kept byte-intact as the superseded prior.)
Change from v0.7. Section 3.3 only. Render's constraints did not forbid Loomworks internal vocabulary or invented illustrations; a legal run surfaced both. Section 3.3's prompt posture gains two additional constraints: no Loomworks internal vocabulary (the "Operator" role name must not appear in prospect-facing prose), and no invented illustrations (render may not manufacture example scenarios, hypothetical timelines, or named incidents that trace to no finding). Both are observed defects from the 2026-07-16 legal run, both are prompt-enforced and therefore soft per section 7. No other section changes. (v0.7 is kept byte-intact as the superseded prior.)
Change from v0.8. Section 3.1 only. v0.8 constrained render against Loomworks internal vocabulary but not analyze; a playbook run produced a finding whose claim text contained "Operator", which the panels then displayed verbatim to a prospect-facing surface. Section 3.1's prompt posture gains a matching constraint: a finding's claim text is displayed verbatim by the contrast and check panels, not paraphrased the way render paraphrases, so "Operator" and other Loomworks internal vocabulary must never appear in a finding. Observed 2026-07-16: a finding read "The commercial legal team lead or General Counsel is the Operator who must confirm each new version" — render correctly paraphrased it away, but the panels displayed it verbatim. This is the same class of guarantee as render's v0.8 constraint, not a stronger one — prompt-enforced and therefore soft, per section 7. No other section changes. (v0.8 is kept byte-intact as the superseded prior.)
Change from v0.9. Section 7 only. Reader-set non-determinism observed during the acceptance run. Section 7 gains a new item: analyze proposes readers by sampling, so the same four fields can produce a different room on a second run — an acceptance run on the playbook input derived a reader set that did not include the Chief Scientific Officer proposed by an earlier run on the identical input, while shape's partition arrays reproduced byte-identical across independent runs on a stored analysis. Not addressed here; noted as a question for the Operator Layer build. No other section changes. (v0.9 is kept byte-intact as the superseded prior.)
Change from v0.10. Section 5 only. Two corrections. First, section 5 specified side-by-side columns, following the mockup's layout — but the mockup made side-by-side look readable only because its reader texts were short hand-written blurbs; real rendered output runs to six paragraphs per reader, and the Operator reported the columns unreadable when judging acceptance criterion 2. Both the reader cards and the rendered readers were specified as grids against the mockup's short hand-written text; both fail on real derived content, so both are replaced with a stacked sequence — one full-width block per reader in the order checked; the comparison work moves to the contrast panel, where it is computed rather than left for the Operator to spot across narrow gutters. Second, section 5 specified the output surface but no way to take the output off the page; the Operator cannot carry a reader's version into a room. Section 5 gains a new subsection, "Taking the output off the page": a per-reader Copy control (plain text, one reader's prose, no page furniture), and a run-level Download control (one HTML file — four inputs, every rendered reader, the computed contrast panel, and the check panel verbatim, including its incompleteness statement, so the fabrication-risk flag travels with the prose it flags). Neither persists — clipboard action and client-side blob only, same posture as the rest of the page. No other section changes. (v0.10 is kept byte-intact as the superseded prior.)
Change from v0.11. Sections 3.3, 4.2, 5, and 10 — a pitch mode is added. The output carried reader-specific columns but no general overview: nothing the Operator says before getting specific to a room. The pitch is a general overview and opportunity, not shaped for any one reader — it runs through shape and render like a reader, but with fixed rules that are structural rather than domain-specific (forward: what the work is, what is hard about it, what becomes possible; cut: role-specific operational detail). It goes through shape so its selection is recorded and auditable and the check panel can scope to it — but it is not a reader: it does not appear in the reader list and does not participate in the contrast panel, which compares readers. The honesty constraint is the point of the pitch: an opportunity is a gap between where the prospect is and where they could be, and the pitch is the highest-fabrication-risk surface in this tool because its genre invites exactly a manufactured "before". Therefore its claims about the prospect's present state must trace to findings with source "input" — what they told the Operator, not what the model guessed; claims about what Loomworks does may draw on any finding; where the input does not establish where they are today, the pitch says what Loomworks does with work of this kind and manufactures no before. No superlatives, no transformation language, no invented pain. Prompt-enforced and therefore soft, per section 7. §3.3 adds the pitch mode; §4.2 extends the check panel to the pitch's inferred findings; §5 places the pitch first, above the rendered readers, with its own Copy control, inclusion in the Download, an explicit on-by-default control separate from the reader list and absent from the fan. §10's acceptance gained a criterion for the pitch (read aloud to the prospect, surviving their corrections), and its criterion 2 still said "columns" after v0.11 replaced them with stacked rendered readers — corrected. No other section changes. (v0.11 is kept byte-intact as the superseded prior.)
The Example Generator asks four questions about a prospect's work and produces one example. This spike adds a fifth question — who is going to read this — and produces one artifact holding a version per reader, side by side.
It is not a variant of the existing generator. The existing chain writes finished prose in its first call, which means there is nothing left to shape afterwards. This spike replaces that with a chain that finds the material first, selects from it per reader second, and writes prose last. That is the only way the fifth question can do real work rather than re-tone the same document.
The spike is disposable. It exists to answer one question: does one analysis genuinely shape differently per reader, or does the model just re-word the same thing? If the answer is yes, the real build goes in the Operator Layer. If no, delete the spike.
analyze.js emits a five-section HTML fragment — finished prose, written for a generic reader. By the time it returns, the selection has already happened: it chose what to say and what to omit, for nobody in particular.
Hand that output to a shaping call and instruct it to address the owner, and the model has two available moves: re-word what survived, or invent material that was never there. Re-toning or fabricating. Neither is Shaping.
This was confirmed by inspection of both models' output on the same input (2026-07-16, perishables). Sonnet's analyze is good prose and has still discarded the structure. The material that makes the strongest case — an unmatched balance of stock, a negotiation trajectory — appears only in illustrate, downstream of where shaping would have to happen.
The lesson applied: a guarantee is enforced in code, not requested in a prompt. Asking a shaping prompt to "select rather than re-tone" cannot work when the upstream call has already thrown the selectable material away. The fix is architectural.
A parallel chain under /api/sales/, and one new page. Four new files:
| File | Route | Role |
|---|---|---|
| functions/api/sales/analyze.js | POST /api/sales/analyze | Four fields → structured findings. No prose. |
| functions/api/sales/shape.js | POST /api/sales/shape | Findings + one reader → a selection over finding IDs. No prose. |
| functions/api/sales/render.js | POST /api/sales/render | Selection + findings → prose for that reader. |
| src/pages/sales-generator.astro | /sales-generator/ | The page. |
functions/api/_lib.js is reused for the Anthropic caller, rate limiting, input caps, and sanitisation. It is not modified — the public generator depends on it. If the spike needs a helper _lib.js does not have, add it to a new functions/api/sales/_lib.js rather than editing the shared one.
The existing analyze.js, illustrate.js, foundation-draft.js, and example-generator.astro are not touched.
analyze — find the material, write for nobodyInput. The four existing fields (work, audience, done, constraints), same 2000-char caps.
Output. Structured JSON. Not HTML, not prose.
{
"findings": [
{
"id": "f1",
"claim": "The window between grade-out and shrink is measured in hours",
"room": "memory" | "manifestation" | "shaping" | "rendering" | "why",
"source": "input" | "inferred",
"weight": "central" | "supporting"
},
...
],
"groups": [
{ "label": "What Memory would hold", "finding_ids": ["f1","f4"] },
...
],
"readers": [
{
"key": "short_stable_key",
"label": "The supervising partner",
"description": "One short line — what they are measured on",
"forward": "What this reader's version leads with",
"cut": "What this reader's version leaves out"
},
...
]
}
Which readers. These are the people who would read this sales material — the room the Operator is walking into at the prospect organization. They are decision-makers and influencers: whoever holds the budget, whoever owns the operational pain, whoever must sign off, whoever assesses the risk. Derived from the domain, in that domain's vocabulary.
They are not readers of the prospect's own work product. For a legal matter, "managing partner" and "general counsel" are readers of this material. "Testifying expert" and "litigation paralegal" are not — they are roles inside the work, and a column shaped for them is a feature description rather than a pitch. The public Example Generator already illustrates how work is shaped for its own readers; that is not what this tool is for.
Where work-product readers belong. Observations about who reads the prospect's work, and what must not cross between them, are valuable — they are findings, not readers. That outside co-counsel must not receive privileged work product is ammunition inside a pitch to a managing partner, not a column of its own. analyze should surface such observations as findings with source "inferred".
The source field is the point of this whole design. input means the finding traces to something the Operator typed. inferred means the model produced it — the Brix number, the assumption that they run a WMS, the claim that they work off spreadsheets today. Every finding is one or the other, and the model must classify each one.
readers is derived, not fixed. Between three and five readers, proposed by the model in the vocabulary of the work it was just given — not the perishables set, not any fixed set. The model proposes; the Operator selects, at generation time, by checking the ones that apply. This replaces a hardcoded four-archetype set (owner, ops lead, food safety/audit, systems lead) that shipped in v0.1–v0.4 — see the Change-from-v0.4 note.
Prompt posture. Find everything worth saying. Organize it. Address nobody. Do not write prose. Emit only the JSON object. Propose the readers of the sales material itself — the decision-makers and influencers at the prospect organization who would read a pitch about adopting something like this, not the people who read or act on the prospect's own work. Grounded in the four fields, in that organization's vocabulary — not a generic template, and not the roles that already exist inside the work being described.
No Loomworks internal vocabulary in findings. A finding's claim text is displayed verbatim by the contrast and check panels — it is not paraphrased the way render paraphrases. Anything a finding says reaches the surface as written. "Operator" is this system's role name and must never appear in a finding; name the actual role in the prospect's world. The four rooms may be named in plain terms; codebase shorthand and internal role names may not. Observed 2026-07-16: a finding read "The commercial legal team lead or General Counsel is the Operator who must confirm each new version" — render correctly paraphrased it away, but the panels displayed it verbatim. This is prompt-enforced and therefore soft, per section 7. It is the same class of guarantee as render's, not stronger.
Validation. Reject if: not valid JSON, any finding missing a field, any finding_ids entry not matching a finding id, any source value outside the enum, zero findings, any reader missing one of its five fields, reader keys not unique, or reader count outside three to five. A malformed readers array fails the whole analyze response, exactly as a malformed findings array does. On failure, surface the plain recovery message (§6). Never render a malformed analysis.
shape — select, do not writeInput. The findings array and exactly one reader key.
Output. A selection over finding IDs. It cannot introduce text.
{
"reader": "<key from the readers array returned by analyze>",
"foregrounded": ["f3","f7"],
"included": ["f1","f4","f9"],
"cut": ["f2","f5","f6","f8"],
"rationale": "What this reader is measured on, and what is therefore not theirs to read."
}
The invariant, enforced in code: every ID in foregrounded, included, and cut must exist in the findings array, and the three lists together must partition it exactly — no ID in two lists, no finding unaccounted for. Reject otherwise.
This is what makes shaping structurally incapable of fabrication. The call selects from a fixed set. It has no field in which to invent.
One call per reader. N readers checked = N shape calls, issued in parallel. They are independent.
render — prose, from the selection onlyInput. One shape selection, plus the findings it references.
Output. HTML fragment for that reader's column. Sanitised via the existing sanitizeFragment before injection.
Prompt posture. Write for this reader using only the findings supplied. Lead with the foregrounded ones. Do not introduce facts that are not in the findings.
No Loomworks internal vocabulary. The reader is a stranger at the prospect organization. "Operator" is this system's role name and must never appear — name the actual person in their world, or say "your". The four rooms may be named in plain terms; codebase shorthand and internal role names may not. Observed 2026-07-16: a rendered column told a law firm's technology director to "wait for the Operator's confirmation."
No invented illustrations. Render may not manufacture example scenarios, hypothetical timelines, or named incidents that trace to no finding. Where a finding warrants an example, the example comes from what the Operator described. Observed 2026-07-16: a column invented a "deponent said on Monday, correction arrives on Friday" scenario with no source finding. This is prompt-enforced and therefore soft, per section 7 — it narrows the fabrication surface, it does not close it.
Note honestly: this last constraint is prompt-enforced, not code-enforced, and is therefore the weakest link in the chain. render is where new fabrication can still enter. This is a known limit of the spike, not a solved problem — see §7.
render runs in parallel per reader, following its shape call.
The pitch. A general overview and opportunity, not shaped for any one reader. It runs through shape and render like a reader, but with fixed rules that are structural rather than domain-specific:
It goes through shape so its selection is recorded and auditable, and so the check panel (§4.2) can scope to what reached it. It is not a reader: it does not appear in the reader list, and it does not participate in the contrast panel (§4.1), which compares readers. The pitch's shape call uses the fixed forward/cut rules above in place of a reader's per-reader rationale; its selection partitions the findings exactly as any shape call does, so it cannot introduce text (§3.2's invariant holds).
The honesty constraint — the point of the pitch. An opportunity is a gap between where the prospect is and where they could be. The model knows four fields; everything else about their present state is inference, and the pitch is the highest-fabrication-risk surface in this tool because its genre invites exactly that — a manufactured "before" that makes the opportunity look larger.
Therefore: the pitch's claims about the prospect's present state must trace to findings with source: "input" — what they told the Operator, not what the model guessed. Claims about what Loomworks does with work of this kind may draw on any finding. If the input does not establish where they are today, the pitch says what Loomworks does with work of this kind and does not manufacture a before.
No superlatives, no transformation language, no invented pain. Realistic means it would survive being read aloud to the prospect with them correcting it.
This is prompt-enforced and therefore soft, per section 7 — like render's no-invented-illustrations constraint, it narrows the fabrication surface, it does not close it. It is the same class of guarantee, applied to the surface where the genre pushes hardest against it.
Both were hand-authored in the mockup. Neither should be.
Given two or more shape selections, the contrast is set arithmetic over finding IDs. No model call. If it can be computed it must not be generated — a generated contrast can claim a difference that is not there.
Two tiers are reported, because one alone misleads.
The sharp tier: foregrounded(A) ∩ cut(B). What one reader leads with and the other refuses. The strongest available signal, and rare — readers often share headline findings while differing underneath.
The broad tier: (foregrounded ∪ included)(A) ∩ cut(B). What A's document carries that B's does not have at all. This is the honest measure of how far two documents differ.
Both directions of both tiers. Where a direction is empty it is omitted, not placeholdered.
The panel leads with the broad tier. The sharp tier is reported when non-empty, marked as the stronger signal. Where both are empty in both directions, the two selections genuinely overlap and the panel says so plainly rather than manufacturing a difference.
Prior position, corrected. CR v0.1 through v0.6 defined contrast solely as foregrounded(A) ∩ cut(B). That definition was measured against two real pairs on 2026-07-16 and found to report 0 where 5 findings differed, and 1 where 9 differed. Both readers led with the same headline findings while their documents diverged substantially underneath — the narrow definition looks exactly where difference is not. It was not a computation error. It would have reported "no contrast" on pairs that differ by a third of the analysis, in a tool whose entire purpose is to show that difference.
source, and incomplete
Every finding where source === "inferred" and that survived into at least one rendered column is a specific the draft asserts about the prospect's business that came from the model, not from the Operator.
That list is the check panel. Filter, do not generate.
The panel is complete with respect to findings. It is not complete with respect to prose. render can introduce specifics that correspond to no finding. Those have no id and no source field, so the filter cannot see them, and no way of building the panel changes that — it audits what analyze guessed, not what render added on top.
This is not theoretical. The step-3 audit (2026-07-16, perishables input, systems-lead reader) found two such specifics in a single rendered column, both asserting things about the prospect's existing tooling that appear in no finding:
Both are hedged and neither invents a number or a named system. Both are assertions about how the prospect works today, produced by a model that was told nothing about how they work today. The owner column, on the same analysis, introduced nothing.
Therefore the panel must not claim completeness on the surface. It says what it is: the specifics the analysis inferred. It does not say or imply that it lists everything unverified in the output. The Operator reads the prose regardless — the panel narrows that job, it does not replace it.
The check panel covers the pitch's inferred findings alongside the readers'. The pitch's shape selection is recorded (§3.3a), so every finding with source === "inferred" that survived into the rendered pitch is filtered onto the panel exactly as a reader's are. The pitch carries the highest fabrication risk of any surface here — its genre invites a manufactured "before" (§3.3a) — and it is not exempt from the audit; its inferred specifics appear on the same list, scoped to what reached the pitch.
Prior position, corrected. CR v0.1 and v0.2 stated at this section that the panel was "complete by construction — nothing inferred can reach the Operator without appearing on the list." That claim was false. It was contradicted within the same document by section 7, which already admitted render can fabricate, and it was disproven in practice at step 3 before the panel was built.
Follows sales-perspective mockup v0_2 for visual language; the flow itself is now two-phase, not the mockup's single-screen form. The mockup's four hardcoded readers are gone along with the fixed archetype set — see the Change-from-v0.4 note.
analyze. Not automatic on blur, not on keystroke, not on a timer. The Operator decides when the call spends, every time.analyze's readers array. Each shows its own label, description, forward, and cut — the model's proposal for this specific work, not a fixed set.shape and render per checked reader, in parallel, exactly as now.shape and render alongside the readers' (§3.3a), in parallel.The reader cards stack too. Each proposed reader is a full-width row, not a cell in a grid: the checkbox and label, the one-line description, then its forward and cut rules at a readable measure. The mockup's grid held four hand-written one-line descriptions. Derived readers carry a description plus a forward rule plus a cut rule — several sentences each — and a two-up grid renders them as tall narrow stacks with ragged empty cells beside them.
The same correction as the rendered readers, for the same reason: the layout was specified against short placeholder text and does not hold real content.
The pitch renders first, above the rendered readers. It is the overview, and the Operator reads it before the role-specific versions — the general opportunity, then who in the room the specifics are for. It is a full-width block like the readers, but it sits at the top and is not one of them.
The rendered readers stack, one above the other, below the pitch, in the order they were checked. Each is a full-width block: the reader's label, then their prose at a readable measure. Not columns. Rendered output runs to several paragraphs per reader, and side-by-side reduces that to unreadable gutters.
The comparison work moves to the contrast panel, which is where it belongs — it computes the difference rather than asking the Operator to spot it across two narrow columns. Section 4.1's two tiers already report what each reader's document carries that another's does not.
Prior position, corrected. CR v0.1 through v0.10 specified side-by-side columns, following the mockup's layout. The mockup made side-by-side look readable only because its reader texts were short hand-written blurbs; real rendered output runs to six paragraphs per reader, and the Operator reported the columns unreadable when judging acceptance criterion 2.
Each rendered reader carries its own Copy control — the Operator will paste one reader's version into one message. Copy takes that reader's prose as plain text, without the surrounding page furniture.
The pitch carries its own Copy control, the same as a reader's — plain text, its prose, no page furniture — and is included in the Download. The overview travels with the run.
The run as a whole carries a Download control taking everything as one file: the four inputs, the pitch, every rendered reader, the computed contrast panel, and the check panel. HTML, so it prints from the browser without a separate Print control.
The check panel travels with the output. A downloaded run carrying the prose without the list of inferred specifics hands the Operator the fabrication risk and withholds the thing that flags it. The check panel's copy — including its statement that it does not cover specifics introduced during rendering — appears in the download verbatim.
Copy on a single reader is the exception: it is a deliberate act on one version, and the Operator has the panel on screen when they do it.
Nothing about this persists. Copy is a clipboard action; Download is a client-side blob. No storage, no server round-trip. Same posture as the rest of the page.
Any validation failure at any stage surfaces one plain recovery message and renders nothing malformed. Name what happened, offer the way out, do not apologise, do not expose the stage that failed. Pattern per D8's recovery surface.
A shape or render failure for one reader must not discard the others. Render the columns that succeeded; name the one that did not.
render can still fabricate. The constraint is in the prompt. Code enforces selection integrity, not prose fidelity. Detecting a fact in the prose that isn't in the findings is a harder problem and is out of scope.source field. The model decides whether a finding came from input or inference. It may be wrong. This is prompt-enforced and therefore soft — but it is soft in one auditable place rather than diffused through the copy._lib.js behaviour, which fails open when RATE_LIMIT_KV is unbound. The binding lives only in the Cloudflare dashboard, not in the repo.Settled by Operator direction, 2026-07-16: the spike sits behind Cloudflare Access from the first deploy. It is reachable from the web, not local-only.
The spike is not public. It is not linked from navigation, the home page, or any sitemap, and carries a noindex robots meta tag — same posture as the Harvest Surge mockups.
The Access application covers both the page and its API routes. /sales-generator/ and /api/sales/ are gated together. Gating the page alone leaves the generation endpoints openly callable, which spends the Anthropic budget without the gate. The page's calls are same-origin and carry the Access session.
The Access application must not extend beyond those two paths. The public Example Generator at /example-generator/, its API routes at /api/analyze, /api/illustrate, /api/foundation-draft, the Harvest Surge mockups at /harvest-surge/, and the marketing site itself all stay open. CC verifies this explicitly before the spike is announced as reachable, and reports what it confirmed.
Known limitation, recorded not solved: the Access application and its policy live on the Cloudflare dashboard, outside version control — the same pattern as the RATE_LIMIT_KV binding. Neither is visible in the repository, and neither survives a repository restore.
Policy membership is an Operator decision and is not specified here. CC does not create or modify the Access policy. The Operator configures it.
analyze.js with its schema and validation. Verify locally: real input returns valid structured findings with sane source classification.shape.js with partition validation. Verify: two readers over one analysis produce genuinely different selections.render.js. Verify: prose per reader from selection only.Halt after step 2 and report. If two readers over one analysis produce near-identical selections, the thesis has failed and steps 3–6 are wasted. That is the cheapest available kill point, and it comes before any prose is written.
The spike is accepted when the Operator can, locally:
Acceptance is not correctness. It means the surface works well enough to answer the thesis question. The Operator answers that by reading the output, not by the tests passing.
RATE_LIMIT_KV bound locally or failed open._lib.js, analyze.js, illustrate.js, foundation-draft.js, and example-generator.astro are unmodified.DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Example Generator — Sales Perspective Spike — CR-2026-152 — v0.12 — 2026-07-17