Forty-five intelligence reports shipped in six months. Each one a one-shot build. The next unlock is not more reports — it is a shared canvas where the team edits, swaps, branches, and attributes in the final design context.
The Claude Code pipeline produces AHA-quality reports end-to-end. What it cannot do is let the team touch the output after the build.
Every deliverable today is a frozen artifact. Content, layout, visual system, and module choices are all baked at build-time. A small edit — add a stat, swap a quote, reorder sections — currently requires re-running the generator, losing prior context.
There is no team surface. No co-editing. No attribution. No version history inside the report. No way to branch a report for a different client without re-building from scratch. This does not scale past where we are.
Iteration cost. A client wants two swapped sections and a different stack-rank table. Today that is a full rebuild. In the editor, it is a module swap + a commit.
Team bottleneck. Only the person running Claude Code can evolve the report. The analyst, the editor, the visual lead — none of them can touch the output directly.
Grammar drift. Without enforcement, each generation interprets the 19-section grammar slightly differently. The editor makes the grammar executable, not aspirational.
Open any report in its final design context. Edit copy, swap modules, add sections, review with the team — all inside the artifact, with every change attributed and versioned.
Think Figma for intelligence briefs, governed by the ShurIQ grammar. The editor reads the grammar schema, surfaces only valid operations, and keeps the report inside the design system at all times.
The team operates on the same artifact: an analyst drafts the reframe paragraph, a visual lead swaps the graph viewport, the lead editor tightens the actionable intelligence block, and the account lead signs off — all in-canvas, all attributed, all versioned.
A report is a tree of modules. Each module has a grammar-defined type (hero, prose, numbers, graph, gap analysis, competitive table, actions, BPS, bridge, etc.), a set of content fields, and one or more render variants. The editor is the only interface that touches that tree.
The grammar is the constraint. You cannot place a BPS block where a numbers block goes. You cannot ship a report missing the reframe. The ontology is enforced at the structural level.
Claude becomes an in-canvas collaborator. Suggest a module. Draft the copy for a gap. Fact-check a stat against InfraNodus. Review anti-slop compliance before publish.
These are the non-negotiable pillars. If the editor cannot do all six, it is a tool. If it does all six, it is the platform.
The report is not the artifact. The module tree is. The HTML is just one render of it.
Six layers. Each independently replaceable. The grammar is the spine; everything else is infrastructure around it.
Every editor decision routes through the schema. This is what makes the tool a platform instead of another rich-text surface.
Today the 19-section grammar lives in documentation (shuriq-report-grammar) and an editorial discipline. The editor converts it into a machine-readable contract that enforces structure, field types, and section ordering.
Type. Hero, prose pair, numbers ribbon, graph section, gap analysis, competitive table, BPS grid, bridge. Closed vocabulary.
Required & optional fields. Hero must have h1 + subtitle + deck. BPS must have composite + 5 dimensions. Gap analysis requires severity-tagged entries.
Render variants. A numbers ribbon can render as 4-up, 3-up, or 2-up. A graph section can render as SVG knowledge graph, gap radar, or discourse flow.
Swap group. Which modules are interchangeable. A gap radar and a stack rank belong to the same slot; the editor surfaces both as valid.
Validation rules. Hero must be first. Bridge must be last. The reframe must appear once between sections 3 and 6. Anti-slop checks on prose fields before publish.
Each phase ends with a usable increment. We never sit on a long internal build with nothing shipped.
Five canonical reports + two grammar docs. The working set for the design session.
Eight questions. Each one unblocks a chunk of Phase 1.
ShurIQ shipped forty-five reports by industrializing one-shot generation. The next forty-five come from collaborative post-production. Same grammar. Same visual system. Same ontology. What changes is who can touch the output, when, and with what attribution. The editor is the next unlock.