study · collaboration · 02

Dididecks vs Instadeck.
One product, two approaches.

Instadeck is phoenixcap’s own full-stack derivative of dididecks-ai. We asked for a version people could log into and use, and she built one. Both generate investor decks, so the comparison is direct. Most of the differences follow from one choice: where the generator runs.

For Lossless
What a server-side generator shows about measuring a deck, and what our own drift looks like from outside.
For phoenixcap
The small developer-harness pieces that would orient the next agent, and two ideas from our review surface.

Not a ranking. Depth below means how much harness exists in a layer, not how good either product is. Each difference is shown with what it makes easier and what it makes harder.

ch · the layer map

Each side put its depth where its generator lives

dididecks-ai generates decks inside an operator’s Claude Code session, so its developer harness doubles as its product harness: deep in context, moderate in the product. Instadeck generates decks in a server pipeline a customer starts, so its product harness is deep, and its developer harness is moderate and walled off from the product on purpose.

dididecks-ai
Instadeck
Developer-agents harnessHow coding agents help build the software.

dididecks-ai · Developer-agentsDeep in context

Inherits the tree’s layered AGENTS.md and CLAUDE.md, shared skills, context-v, changelog and git conventions, and the corpus. Its own 133-line CLAUDE.md, 70 context-v files (15 plans, 9 data models, a 29-file living sitemap) and 17 changelog entries. Thin in verification: no tests, and CI only deploys the splash.

context and orientationdididecks-ai to Instadeck
tests that pin docsInstadeck to dididecks-ai

Instadeck · Developer-agentsModerate

Rigorous where it bears on correctness: a spec of record with change control, contract tests that pin docs and the runtime prompt, one CI workflow running about 27 test files, dated gate, rollback and review records, one branch per concern. Thin on orientation: no instruction file on main since 09-29.

In-product-agents harnessHow the product’s own agents generate decks.

dididecks-ai · In-product-agentsModerate

The generator is Claude Code, run by an operator. Its method is written down: deck-iteration-workflow, slide-target, the Scroll-UI and Play-UI rule, per-slide narratives and a DESIGN.md per client, a shell with an in-place rank pill and a review matrix, an export CLI. Nothing runs without an operator, and nothing measures output.

measurement, proof, repairInstadeck to dididecks-ai
variants, human rankdididecks-ai to Instadeck

Instadeck · In-product-agentsDeep

A canonical prompt that a test keeps identical to the spec, a persisted Markdown document chain with hashes, 19 product SKILL.md files and two typed catalogues, failure-driven repair skills, a frozen render corpus, offline and live acceptance runners, durable jobs with lineage, and a written rule that technical validity is not creative success.

The bold arrow in each row runs from the deeper side: context and orientation from dididecks-ai in the developer layer, measurement, proof and repair from Instadeck in the product layer. The thin arrow runs back: tests that pin documents, and variants a human ranks.

Why “moderate” for our product layer. dididecks-ai has no runtime prompt, no model call, no evaluation and no tests in the product. By an automated pipeline’s standard it is thin. But its product is a coding-agent session with about 4,500 lines of skills, a design contract per deck, a review surface and an export path. A reader who counts only automation should read it as thin.

Two carriers, or one. On our side Claude Code, the skills and context-v serve both the developer and the deck generator. On hers the layers are separated by design, down to a test that keeps operator notes out of product context.

ch · highlights

Highlights

convergence · product layer

Markdown first, and a DESIGN.md per deck.

Both write the deck as Markdown before rendering it: per-slide files with typed frontmatter, plus a per-deck design contract (ours via maintain-design-md, hers as 06-DESIGN.md). Both reason about the whole deck before any slide. She tried a simpler path in PR 40 and reversed it in PR 47.

instadeck goes deeper · verification

Verification, in both layers.

120 backend test files, tests that pin the spec and the runtime prompt byte for byte, a frozen render corpus, a read-only live acceptance runner, and a written rule that “technically valid” is not success. dididecks-ai has no tests; its one workflow deploys the splash.

dididecks-ai goes deeper · context

Context, for the next agent.

A 133-line CLAUDE.md, 9 data-model docs written for her, a 29-file living sitemap, 15 plans and 17 changelog entries, plus the tree’s shared skills and corpus. Instadeck’s main has had no instruction file since 09-29; a shorter reset set waits on a branch.

different users · stack

The author signs in, or the reader does.

Instadeck is a multi-tenant web product where the author signs in. dididecks-ai is a set of per-client Astro sites where the reader signs in and git is the content store.

our own drift · dev layer

Her prompt test answers our drift.

Five of the 18 skills in dididecks-ai’s in-repo snapshot differ from the anchor copies, and one exists only in the snapshot. A pin like hers is the first recommendation for us.

  • Developer layer25 ledger rows
    • Shared 3
    • Similar 10
    • Different 8
    • Missing 4
    Dominated by similar, which fits a shared lineage. Different rows split four each way.
  • In-product layer17 ledger rows
    • Shared 2
    • Similar 8
    • Different 2
    • Missing 5
    Also mostly similar. Of nine missing rows across both layers, eight run toward us, all about verification.

ch · the harness maps

The harness maps, one per layer

Every artifact either side keeps, grouped by category and compared only within its layer. Lines join pairs, and each line names its bucket in words. A box with no line has no counterpart on the other side.

  • shared: solid amber
  • similar: dashed cyan
  • missing on one side: dashed plum
  • different by design: plain

Developer-agents harness

Harness map: developer-agents layer Developer-agents harness. dididecks-ai on the left, Instadeck on the right, artifacts grouped by category. Each line joins a pair and is labelled shared, similar, different by design, or missing on our side. Three pairs are shared and ten similar. All four missing lines are verification pieces that Instadeck has and dididecks-ai lacks: CI that runs tests, tests at all, tests that pin documents, and a review packet. Unpaired boxes are differences that fit each side: her release records and archive branches, our pseudomonorepo machinery. AGENTS.md, CLAUDE.md · layered: anchor to app · dididecks-ai: developer harness (deep in context) AGENTS.md, CLAUDE.md layered: anchor to app AGENTS.md ×3, then reset · none on main since 09-29 · Instadeck: developer harness (moderate) AGENTS.md ×3, then reset none on main since 09-29 README.md · specs, sites, skills · dididecks-ai: developer harness (deep in context) README.md specs, sites, skills README.md · routes to product/ · Instadeck: developer harness (moderate) README.md routes to product/ .gitignore · .claude/ kept out · dididecks-ai: developer harness (deep in context) .gitignore .claude/ kept out .gitignore · .codex*, Bitácora kept out · Instadeck: developer harness (moderate) .gitignore .codex*, Bitácora kept out vercel.json, pages.yml · static sites · dididecks-ai: developer harness (deep in context) vercel.json, pages.yml static sites railway.toml ×4 · migrations before start · Instadeck: developer harness (moderate) railway.toml ×4 migrations before start Deployment gate, rollback · dated release records · Instadeck: developer harness (moderate) Deployment gate, rollback dated release records context-v/specs · north star, Draft · dididecks-ai: developer harness (deep in context) context-v/specs north star, Draft product/ spec of record · change control, ledger · Instadeck: developer harness (moderate) product/ spec of record change control, ledger context-v/plans (15) · status in frontmatter · dididecks-ai: developer harness (deep in context) context-v/plans (15) status in frontmatter Plans, status line first · render repair: six slices · Instadeck: developer harness (moderate) Plans, status line first render repair: six slices Explorations, reminders · reasoning, loose ends · dididecks-ai: developer harness (deep in context) Explorations, reminders reasoning, loose ends Decision, recovery records · say what they withhold · Instadeck: developer harness (moderate) Decision, recovery records say what they withhold Sitemap (29), FILEMAP · a file per route · dididecks-ai: developer harness (deep in context) Sitemap (29), FILEMAP a file per route Runtime inventory · the mounted customer path · Instadeck: developer harness (moderate) Runtime inventory the mounted customer path context-v/models (9) · written for her · dididecks-ai: developer harness (deep in context) context-v/models (9) written for her Codex knowledge pack · build briefs from ours · Instadeck: developer harness (moderate) Codex knowledge pack build briefs from ours changelog/ (17) · checked in, rolled up · dididecks-ai: developer harness (deep in context) changelog/ (17) checked in, rolled up Bitácora · local only since 09-18 · Instadeck: developer harness (moderate) Bitácora local only since 09-18 context-v conventions · the repo is the memory · dididecks-ai: developer harness (deep in context) context-v conventions the repo is the memory Adopted, then removed · a test forbids them · Instadeck: developer harness (moderate) Adopted, then removed a test forbids them Browser-drive blueprint · tree-wide rules · dididecks-ai: developer harness (deep in context) Browser-drive blueprint tree-wide rules Live acceptance runbook · exit zero or not done · Instadeck: developer harness (moderate) Live acceptance runbook exit zero or not done No test CI · CI deploys the splash · dididecks-ai: developer harness (deep in context) No test CI CI deploys the splash CI: ~27 test files · no paid calls · Instadeck: developer harness (moderate) CI: ~27 test files no paid calls No tests · typecheck only · dididecks-ai: developer harness (deep in context) No tests typecheck only 120 backend test files · ~21.5k lines · Instadeck: developer harness (moderate) 120 backend test files ~21.5k lines No doc-pinning tests · discipline, frontmatter · dididecks-ai: developer harness (deep in context) No doc-pinning tests discipline, frontmatter Spec and prompt pins · asserted by tests · Instadeck: developer harness (moderate) Spec and prompt pins asserted by tests No review packet · no handoff folder · dididecks-ai: developer harness (deep in context) No review packet no handoff folder Independent review packet · unfinished, do not merge · Instadeck: developer harness (moderate) Independent review packet unfinished, do not merge git-conventions, 3 tiers · bodies, Claude trailers · dididecks-ai: developer harness (deep in context) git-conventions, 3 tiers bodies, Claude trailers Branch per concern, PRs · squash merges · Instadeck: developer harness (moderate) Branch per concern, PRs squash merges Claude Code · skills by description · dididecks-ai: developer harness (deep in context) Claude Code skills by description Codex · one prompt at a time · Instadeck: developer harness (moderate) Codex one prompt at a time Archive branches · plus CI patch transport · Instadeck: developer harness (moderate) Archive branches plus CI patch transport Pseudomonorepo rules · Stow skills, corpus, splash · dididecks-ai: developer harness (deep in context) Pseudomonorepo rules Stow skills, corpus, splash similar shared shared shared similar similar similar similar similar similar different by design similar missing on our side missing on our side missing on our side missing on our side similar similar dididecks-ai: developer harness (deep in context) Instadeck: developer harness (moderate) Legend Instructions Verification Context and memory Config and deploy Git and coding agent Tree machinery

Instructions

  • dididecks-aiAGENTS.md, CLAUDE.mdlayered: anchor to appsimilarInstadeckAGENTS.md ×3, then resetnone on main since 09-29
  • dididecks-aiREADME.mdspecs, sites, skillssharedInstadeckREADME.mdroutes to product/

Config and deploy

  • dididecks-ai.gitignore.claude/ kept outsharedInstadeck.gitignore.codex*, Bitácora kept out
  • dididecks-aivercel.json, pages.ymlstatic sitessharedInstadeckrailway.toml ×4migrations before start
  • dididecks-ai—different, no counterpartInstadeckDeployment gate, rollbackdated release records

Context and memory

  • dididecks-aicontext-v/specsnorth star, DraftsimilarInstadeckproduct/ spec of recordchange control, ledger
  • dididecks-aicontext-v/plans (15)status in frontmattersimilarInstadeckPlans, status line firstrender repair: six slices
  • dididecks-aiExplorations, remindersreasoning, loose endssimilarInstadeckDecision, recovery recordssay what they withhold
  • dididecks-aiSitemap (29), FILEMAPa file per routesimilarInstadeckRuntime inventorythe mounted customer path
  • dididecks-aicontext-v/models (9)written for hersimilarInstadeckCodex knowledge packbuild briefs from ours
  • dididecks-aichangelog/ (17)checked in, rolled upsimilarInstadeckBitácoralocal only since 09-18
  • dididecks-aicontext-v conventionsthe repo is the memorydifferent by designInstadeckAdopted, then removeda test forbids them

Verification

  • dididecks-aiBrowser-drive blueprinttree-wide rulessimilarInstadeckLive acceptance runbookexit zero or not done
  • dididecks-aiNo test CICI deploys the splashmissing on our sideInstadeckCI: ~27 test filesno paid calls
  • dididecks-aiNo teststypecheck onlymissing on our sideInstadeck120 backend test files~21.5k lines
  • dididecks-aiNo doc-pinning testsdiscipline, frontmattermissing on our sideInstadeckSpec and prompt pinsasserted by tests
  • dididecks-aiNo review packetno handoff foldermissing on our sideInstadeckIndependent review packetunfinished, do not merge

Git and coding agent

  • dididecks-aigit-conventions, 3 tiersbodies, Claude trailerssimilarInstadeckBranch per concern, PRssquash merges
  • dididecks-aiClaude Codeskills by descriptionsimilarInstadeckCodexone prompt at a time
  • dididecks-ai—different, no counterpartInstadeckArchive branchesplus CI patch transport

Tree machinery

  • dididecks-aiPseudomonorepo rulesStow skills, corpus, splashdifferent, no counterpartInstadeck—
dididecks-ai on the left, Instadeck on the right. All four missing lines are verification, and all are on our side. On a narrow screen the map stacks into pairs.

In-product-agents harness

Harness map: in-product-agents layer In-product-agents harness. dididecks-ai on the left, Instadeck on the right, artifacts grouped by category. Skills and the Chromium render are shared; eight pairs are similar, including the Markdown document chain. Four lines are missing on our side (a prompt pin, measured repair, a frozen corpus, acceptance runners) and one on hers (variants kept side by side per slot). Memory is different by design, and our planned embedded chat has no counterpart. Deck skills · theme, DESIGN, ingest · dididecks-ai: product harness (moderate) Deck skills theme, DESIGN, ingest 19 product SKILL.md · registry, tool whitelist · Instadeck: product harness (deep) 19 product SKILL.md registry, tool whitelist deck-iteration-workflow · Scroll first, then Play · dididecks-ai: product harness (moderate) deck-iteration-workflow Scroll first, then Play Canonical prompt · kept equal to the spec · Instadeck: product harness (deep) Canonical prompt kept equal to the spec slide-target · first of a slide-* family · dididecks-ai: product harness (moderate) slide-target first of a slide-* family Prompt packages · nine, with schemas · Instadeck: product harness (deep) Prompt packages nine, with schemas Skill pack copies · five have drifted · dididecks-ai: product harness (moderate) Skill pack copies five have drifted Prompt pin test · plus LLM machinery tests · Instadeck: product harness (deep) Prompt pin test plus LLM machinery tests Narratives NN-slug.md · plus DESIGN.md per client · dididecks-ai: product harness (moderate) Narratives NN-slug.md plus DESIGN.md per client 01-source to 06-DESIGN · then slides/sNN.md · Instadeck: product harness (deep) 01-source to 06-DESIGN then slides/sNN.md Slide archetype corpus · 27 archetypes, data/ · dididecks-ai: product harness (moderate) Slide archetype corpus 27 archetypes, data/ llm_knowledge · 195 files · Instadeck: product harness (deep) llm_knowledge 195 files Spec row to component · June exploration · dididecks-ai: product harness (moderate) Spec row to component June exploration DeckSpec plus compiler · built, left unmounted · Instadeck: product harness (deep) DeckSpec plus compiler built, left unmounted Claude Code + deck-shell · an operator drives it · dididecks-ai: product harness (moderate) Claude Code + deck-shell an operator drives it Whole-deck HTML service · runs unattended · Instadeck: product harness (deep) Whole-deck HTML service runs unattended deck-export · the browser produces · dididecks-ai: product harness (moderate) deck-export the browser produces Chromium proof · the browser checks · Instadeck: product harness (deep) Chromium proof the browser checks Play-UI step · nothing measures it · dididecks-ai: product harness (moderate) Play-UI step nothing measures it Measured repair skills · failure to bounded fix · Instadeck: product harness (deep) Measured repair skills failure to bounded fix Rank pill, DeckMatrix · continuous, in place · dididecks-ai: product harness (moderate) Rank pill, DeckMatrix continuous, in place Visual audit scorecard · eight dimensions, once · Instadeck: product harness (deep) Visual audit scorecard eight dimensions, once DD citation popover · sources on the slide · dididecks-ai: product harness (moderate) DD citation popover sources on the slide Due Diligence runtime · off the investor slides · Instadeck: product harness (deep) Due Diligence runtime off the investor slides No frozen corpus · 51 exported slides · dididecks-ai: product harness (moderate) No frozen corpus 51 exported slides Frozen corpus, evidence · provider-free · Instadeck: product harness (deep) Frozen corpus, evidence provider-free Human walk-through · acceptance by eye · dididecks-ai: product harness (moderate) Human walk-through acceptance by eye Offline and live runners · 11 conditions · Instadeck: product harness (deep) Offline and live runners 11 conditions Variants per slot · ranked by a human · dididecks-ai: product harness (moderate) Variants per slot ranked by a human One result per run · per upload · Instadeck: product harness (deep) One result per run per upload The repo is the memory · the client folder · dididecks-ai: product harness (moderate) The repo is the memory the client folder Operation-scoped memory · walled from dev notes · Instadeck: product harness (deep) Operation-scoped memory walled from dev notes Embedded chat, planned · local-first app · dididecks-ai: product harness (moderate) Embedded chat, planned local-first app shared similar similar missing on our side similar similar similar similar shared missing on our side similar similar missing on our side missing on our side missing on her side different by design dididecks-ai: product harness (moderate) Instadeck: product harness (deep) Legend Generator and render Documents and knowledge Skills and prompts Judgement and evaluation Memory and runtime

Skills and prompts

  • dididecks-aiDeck skillstheme, DESIGN, ingestsharedInstadeck19 product SKILL.mdregistry, tool whitelist
  • dididecks-aideck-iteration-workflowScroll first, then PlaysimilarInstadeckCanonical promptkept equal to the spec
  • dididecks-aislide-targetfirst of a slide-* familysimilarInstadeckPrompt packagesnine, with schemas
  • dididecks-aiSkill pack copiesfive have driftedmissing on our sideInstadeckPrompt pin testplus LLM machinery tests

Documents and knowledge

  • dididecks-aiNarratives NN-slug.mdplus DESIGN.md per clientsimilarInstadeck01-source to 06-DESIGNthen slides/sNN.md
  • dididecks-aiSlide archetype corpus27 archetypes, data/similarInstadeckllm_knowledge195 files
  • dididecks-aiSpec row to componentJune explorationsimilarInstadeckDeckSpec plus compilerbuilt, left unmounted

Generator and render

  • dididecks-aiClaude Code + deck-shellan operator drives itsimilarInstadeckWhole-deck HTML serviceruns unattended
  • dididecks-aideck-exportthe browser producessharedInstadeckChromium proofthe browser checks
  • dididecks-aiPlay-UI stepnothing measures itmissing on our sideInstadeckMeasured repair skillsfailure to bounded fix

Judgement and evaluation

  • dididecks-aiRank pill, DeckMatrixcontinuous, in placesimilarInstadeckVisual audit scorecardeight dimensions, once
  • dididecks-aiDD citation popoversources on the slidesimilarInstadeckDue Diligence runtimeoff the investor slides
  • dididecks-aiNo frozen corpus51 exported slidesmissing on our sideInstadeckFrozen corpus, evidenceprovider-free
  • dididecks-aiHuman walk-throughacceptance by eyemissing on our sideInstadeckOffline and live runners11 conditions
  • dididecks-aiVariants per slotranked by a humanmissing on her sideInstadeckOne result per runper upload

Memory and runtime

  • dididecks-aiThe repo is the memorythe client folderdifferent by designInstadeckOperation-scoped memorywalled from dev notes
  • dididecks-aiEmbedded chat, plannedlocal-first appdifferent, no counterpartInstadeck—
dididecks-ai on the left, Instadeck on the right. Four missing lines on our side, one on hers: variants per slot. On a narrow screen the map stacks into pairs.

ch · the loops

The loops, per layer

Same four lanes in every diagram. The two in-product loops share a spine: source, brand, research, narrative, design contract, whole deck, per-slide files, render, export. They differ in who closes the loop.

Developer loops

Instadeck. A spec or dated decision, then a Codex brief (a prompt pack or a one-off), one branch per concern, contract tests and CI, a pull request squash-merged to main, gate, rollback and review records, then a Railway deploy with migrations first. When a direction doesn’t hold, the loop goes back to the spec to simplify or restore.

dididecks-ai. An exploration or spec in context-v, a plan per phase, Claude Code loading the layered CLAUDE.md files and skills, a browser walk with no automated tests, a changelog entry and sitemap status flip, a commit to development, then pointer bumps, a shell release and per-site deploys. 111 commits, 99 with a Claude co-author trailer, no PR merges.

Instadeck · developer loop
Instadeck: developer loop Instadeck's developer loop in four lanes. A spec or dated decision, a Codex brief, one branch per concern, contract tests and CI, a pull request squash-merged to main, gate, rollback and review records, then a Railway deploy with migrations first. The reasons for a change live in PR titles and dated docs. 01 / Human 02 / Agent 03 / Checks 04 / Records Spec Brief Agent work Verify Merge, record, deploy Spec or decision · product/ or dated docs/ · Human › Spec Spec or decision product/ or dated docs/ PR, squash merge · to main · Human › Merge, record, deploy PR, squash merge to main Railway deploy · migrations first · Human › Merge, record, deploy Railway deploy migrations first Brief Codex · prompt pack or one-off · Agent › Brief Brief Codex prompt pack or one-off Branch per concern · one narrow job · Agent › Agent work Branch per concern one narrow job Tests and CI · contracts, frozen corpus · Checks › Verify Tests and CI contracts, frozen corpus Gate, rollback · review records · Records › Merge, record, deploy Gate, rollback review records PR titles, docs/ · where the why lives · Records › Merge, record, deploy PR titles, docs/ where the why lives Legend Spec and brief Agent work and checks Merge and deploy Records
dididecks-ai · developer loop
dididecks-ai: developer loop The dididecks-ai developer loop in the same four lanes. An exploration or spec in context-v, a plan per phase, Claude Code implementing with layered CLAUDE.md files and skills, a browser walk with no automated tests, a changelog entry and sitemap status flip, a commit to development, submodule pointer bumps and a shell release, then Vercel and Pages deploys. 01 / Human 02 / Agent 03 / Checks 04 / Memory Idea Plan Agent work Verify Record, commit, deploy Exploration or spec · in context-v · Human › Idea Exploration or spec in context-v Vercel, Pages · each site, the splash · Human › Record, commit, deploy Vercel, Pages each site, the splash Plan per phase · context-v/plans · Agent › Plan Plan per phase context-v/plans Implement · CLAUDE.md layers, skills · Agent › Agent work Implement CLAUDE.md layers, skills Commit · to development · Agent › Record, commit, deploy Commit to development Bump pointers · publish the shell · Agent › Record, commit, deploy Bump pointers publish the shell Browser walk · no automated tests · Checks › Verify Browser walk no automated tests Changelog entry · sitemap status flip · Memory › Record, commit, deploy Changelog entry sitemap status flip Legend Context Agent work and checks Commit and deploy Memory Person or trigger

In-product loops: two deck generators

Instadeck: the customer uploads, the pipeline generates. Deterministic extraction, source design review and BrandDNA, bounded research, an investor story and redesign plan, 06-DESIGN.md, then slides/sNN.md and whole-deck HTML. Chromium proves the render. A failure is measured and handed to a repair skill; a pass publishes an immutable DesignVersion. The loop closes on a machine measurement.

dididecks-ai: the operator drives Claude Code. Source deck, brief and call notes; a brand import and DESIGN.md; people and companies ingested; a narrative per slide; then phase 1, the whole deck as one Scroll-UI page. A human ranks each slot in place. A weak slot gets a new variant; a strong one is recreated as a 16:9 Play-UI file and exported. The loop closes on a human verdict.

Instadeck · in-product loop
Instadeck: in-product loop (customer uploads, pipeline generates) Instadeck's in-product loop. A customer uploads a deck; the pipeline reviews and researches it, writes the Markdown document chain up to 06-DESIGN.md, and authors whole-deck HTML from per-slide files. Chromium proves the render: a measured failure goes to a repair skill and back, a pass publishes an immutable DesignVersion. One result per run. 01 / Customer 02 / Pipeline 03 / Checks 04 / Records Source Review, research Documents Whole deck Prove, then publish Upload a deck · PDF or PPTX · Customer › Source Upload a deck PDF or PPTX One result · per run · Customer › Prove, then publish One result per run Review, research · BrandDNA, AI-VC skills · Pipeline › Review, research Review, research BrandDNA, AI-VC skills Whole-deck HTML · from slides/sNN.md · Pipeline › Whole deck Whole-deck HTML from slides/sNN.md Repair skill · for the measured failure · Pipeline › Prove, then publish Repair skill for the measured failure Chromium proof? · geometry, assets · Checks › Prove, then publish Chromium proof? geometry, assets Document chain · 01-source to 06-DESIGN · Records › Documents Document chain 01-source to 06-DESIGN DesignVersion · immutable, exported · Records › Prove, then publish DesignVersion immutable, exported pass fail retry Legend Inputs and research Generation and checks Repair Documents and versions Person
dididecks-ai · in-product loop
dididecks-ai: in-product loop (operator drives Claude Code) The dididecks-ai in-product loop. An operator brings source material; Claude Code writes the DESIGN.md and ingests people and companies, writes a narrative file per slide, and builds the whole deck as one Scroll-UI page. A human ranks each slot in place: a weak slot gets a new variant and goes back, a strong one is recreated as a 16:9 Play-UI file and exported. 01 / Operator 02 / Claude Code 03 / Review 04 / Repo Source Brand, research Documents Whole deck Rank, then recreate Source material · deck, brief, call notes · Operator › Source Source material deck, brief, call notes deck-export · PNG, PDF, PPTX, Keynote · Operator › Rank, then recreate deck-export PNG, PDF, PPTX, Keynote DESIGN.md, ingest · brand, people, companies · Claude Code › Brand, research DESIGN.md, ingest brand, people, companies Scroll-UI page · whole deck first · Claude Code › Whole deck Scroll-UI page whole deck first New variant · slide-target pass · Claude Code › Rank, then recreate New variant slide-target pass Human ranks slot? · in place, as read · Review › Rank, then recreate Human ranks slot? in place, as read Narratives · NN-slug.md per slide · Repo › Documents Narratives NN-slug.md per slide Play-UI files · 16:9, recreated · Repo › Rank, then recreate Play-UI files 16:9, recreated strong weak retry Legend Inputs and research Generation and checks Variant Files in the repo Person

ch · shape against harness

Shape against harness

On her side, instructions converge on one file of record per surface, and tests keep code and documents from drifting apart. On ours, instructions are layered by tree level, and the per-client folders are both documentation and the generator’s working memory.

Shape against harness: one repo against a tree Left: Instadeck, one repo with two apps. README routes to the product spec of record, which tests pin; the backend holds the product harness (prompts, skills, knowledge), and a wall keeps repo memory out of it. Right: dididecks-ai inside a tree. The anchor AGENTS.md leads to the ai-labs and dididecks-ai CLAUDE.md files, then to the deck-shell package and seven client sites. Shared skills feed both the repo and each client folder, and Claude Code reads all of it to generate. README.md · routes to product/ · Instadeck: one repo, two apps, four services README.md routes to product/ product/ · spec of record · Instadeck: one repo, two apps, four services product/ spec of record frontend/ · SvelteKit · Instadeck: one repo, two apps, four services frontend/ SvelteKit backend/ · FastAPI, workers, renderer · Instadeck: one repo, two apps, four services backend/ FastAPI, workers, renderer Tests pin the docs · spec, prompt, genesis · Instadeck: one repo, two apps, four services Tests pin the docs spec, prompt, genesis Product harness · prompts, skills, knowledge · Instadeck: one repo, two apps, four services Product harness prompts, skills, knowledge The wall · no context-v or Bitácora · Instadeck: one repo, two apps, four services The wall no context-v or Bitácora Anchor AGENTS.md · tree-wide rules · dididecks-ai: a pseudomonorepo inside a tree Anchor AGENTS.md tree-wide rules ai-labs CLAUDE.md · pseudomonorepo level · dididecks-ai: a pseudomonorepo inside a tree ai-labs CLAUDE.md pseudomonorepo level dididecks-ai CLAUDE.md · Scroll-UI vs Play-UI · dididecks-ai: a pseudomonorepo inside a tree dididecks-ai CLAUDE.md Scroll-UI vs Play-UI Shared skills · Stow, plus a snapshot · dididecks-ai: a pseudomonorepo inside a tree Shared skills Stow, plus a snapshot deck-shell · one package · dididecks-ai: a pseudomonorepo inside a tree deck-shell one package 7 client sites · submodules · dididecks-ai: a pseudomonorepo inside a tree 7 client sites submodules Per client · narratives, DESIGN.md · dididecks-ai: a pseudomonorepo inside a tree Per client narratives, DESIGN.md Claude Code · reads it all to generate · dididecks-ai: a pseudomonorepo inside a tree Claude Code reads it all to generate kept out Instadeck: one repo, two apps, four services dididecks-ai: a pseudomonorepo inside a tree Legend Instructions and spec In-product harness Context and memory Tests and skills Repo shape

One repo, two apps, four services. Instadeck holds a SvelteKit frontend/ and a FastAPI backend/ with workers and a renderer, deployed as separate Railway services. README routes readers to product/; the product harness sits in the backend, behind a wall that keeps repo memory out.

A pseudomonorepo inside a tree. dididecks-ai is a pnpm workspace inside ai-labs, inside the anchor monorepo. It holds an Astro integration (the deck shell, v0.4.0), her SvelteKit shell, an export CLI, and seven client deck sites as submodules, each its own repo and Vercel deploy.

ch · stack against harness

The stacks answer different users

Instadeck is a multi-tenant web product where the author signs in. dididecks-ai is a set of per-client sites where the reader signs in and git is the content store. Each stack shapes what users can do alone, and what an agent has to hold in its head.

dididecks-aiInstadeck
Shapepnpm workspace: Astro integration, SvelteKit shell, export CLI, shared types, seven client sites as submodulesOne repo, two apps; API, worker, renderer and frontend as separate Railway services
Front endClient sites: Astro 6, Tailwind 4 on Vercel. The shell: an Astro 7 integration on a package registry. Her apps/frontend: SvelteKit 2 with an in-memory mock backendSvelteKit 2, Svelte 5, adapter-node, zod; routes for sign-up, dashboard, decks, versions, export, shared decks
Back endNone as a service. Dev-only Astro routes (/api/slide-rank, /api/slide-decompose) write into the client site’s working treeFastAPI, SQLAlchemy 2, Pydantic 2, two Alembic lineages, LangGraph and LangChain, PyMuPDF, Playwright, OpenTelemetry
DataGit is the content store: TypeScript registries, Markdown with frontmatter, an audits JSON. Reader access and telemetry in astro:db (libSQL, Turso); a migration off it is plannedPostgres with pgvector; a job queue on Postgres; S3-compatible object storage
Who signs inThe reader, per deck: access tiers, single-use links, OAuth, magic links. Authors are operators with repo accessThe author: accounts, workspaces, an admin
DeployVercel per client site from a git push; GitHub Pages for the splash; shell versions published and bumped per consumerRailway: pre-deploy runs both migration lineages, a product-ready health check, restart on failure; a written gate and rollback record
ModelsClaude through Claude Code, at author time. The spec plans an embedded Claude chatOpenAI as the single product provider (reset instructions); earlier routing across four providers kept on an archive branch
Exportdeck-export: Playwright drives a running site to @2x PNG, outlined SVG, vector-text PDF, PPTX and real KeynoteRender-proven HTML, publication of an exact DesignVersion, an export service

What Instadeck’s stack makes easier

  • For users: anyone can sign up, upload a deck and come back to it. Results persist per account and per version; nobody needs a repo, a terminal or an operator.
  • For agents: typed boundaries everywhere (Pydantic extra="forbid", JSON Schemas for model output, versioned contract names) give an agent contracts to read and tests to run. A migration history tells it what the data looks like.

What it makes harder

  • For users: the product decides the pipeline. A user who wants a slide no stage contract anticipates waits for Smart Edit or Smart Deck.
  • For agents: four services, two migration lineages and a coordinated deploy order are a lot to hold at once, which is why the gate and rollback record exist. A 10,982-line generation service is expensive to load. Every change has to be safe for strangers’ data.

What dididecks-ai’s stack makes easier

  • For users: each deck is its own site, with its own brand, URL and access rules; a reader gets a link, not an account. Anything a designer can build in Astro can appear on a slide.
  • For agents: Astro components and Markdown are what models write well. The whole deck is plain files an agent can read, diff and revert, with no content migrations and no shared database to break.

What it makes harder

  • For users: nobody outside the team can make a deck alone. The spec says the managing partner will not open a terminal. Authoring needs an operator and a build.
  • For agents: seven consumers of one shell across Astro 6 and 7, pointers to bump, a package to version. And Play-UI, the surface that ships, is the one CLAUDE.md says Claude is bad at.

ch · three trade-offs

Data, architecture, failure

Three choices where each side fits the content it holds and the people it serves. Hers is multi-tenant: many users, private uploads, immutable versions with lineage. Ours is engagement-shaped: a handful of clients, each team iterating on a few decks for weeks.

Postgres records against files in git

Files in git (dididecks-ai)Postgres records (Instadeck)
Unit of contentA file: a slot in slides.ts, a narrative NN-slug.md, a slide component per variantA row: deck, operation, working document (with a SHA-256 of its Markdown), DesignVersion
HistoryGit history; variants kept side by side; /api/slide-decompose refuses to overwriteExplicit lineage records; publication never rewrites a prior version
IsolationOne repo and one deploy per clientWorkspaces in one database
What an agent seesEverything in the client folder, including prior decisionsWhatever the API and tests expose; production data is out of reach by design
SearchThe Chroma corpus, outside the product, for the operator’s agentpgvector in the same database; a bounded design-memory retrieval is specified
Cost of changeEdit a file, commit, pushMigrations, deploy order, rollback planning

Files make easier

  • Cheap iteration, and an agent that works with full context.
  • Every abandoned idea is one git log away.

Files make harder

  • Multi-tenancy, self-serve and access control, which is why our reader access already lives in a database and context-v/models/ sketches a remote one.

Records make easier

  • Per-user persistence, sharing, quotas and audit come naturally.
  • Provenance: it is possible to prove what produced a given slide.

Records make harder

  • Ad hoc creative work: every new kind of artifact needs a schema, a migration and a test. Her own spec warns: prove that the same requirement cannot be represented clearly in the working Markdown documents.

One repo of services against a tree of client sites

Her repo is a modular monolith in source and a set of services at runtime. Ours is a tree: a shared shell, many thin client repos, conventions above.

One repo makes easier

  • One place to look, one spec of record, one CI, and one PR that shows everything a change touched.
  • Tests that reach across the front-end and back-end boundary: one test reads specs, routes and services.

One repo makes harder

  • Some files grow without a natural boundary, like the 10,982-line generation service.
  • Copied-in workflows stopped running without anyone noticing, because GitHub reads only the root workflows folder.

A tree makes easier

  • Client work stays isolated: separate repos, access and deploys.
  • Generic parts are lifted into the shell only after a second client needs them.
  • An agent on one client loads only that client.

A tree makes harder

  • A shell change reaches seven consumers through a package version and seven pointer bumps.
  • Instructions repeat at each level and drift.
  • Cross-cutting checks have no single home, which is part of why there are none.

Failure isolation

Instadeck

  • API, worker and renderer are separate services.
  • Durable jobs survive restarts, a stale-job rescuer exists, and the spec requires terminal failures to be visible.
  • The shared trunk is Postgres: API, queue and lineage all depend on it.

dididecks-ai

  • Each client site is its own deploy, so one client’s outage or bad build doesn’t touch another. Each consumer pins a shell version.
  • No server-side generator to fail. The failure mode is human: generation stops when no operator is at the keyboard, and a deck is only as current as the last session.
  • Reader access depends on libSQL per site.

For both sides: her trunk risk is one database; ours is one operator. Neither is wrong for its stage, and each side’s next step is the other’s strength. Her product could keep a “last good” static export per deck that serves when the API is down, as our Vercel sites do by construction. Ours could let a reader-facing deck regenerate a slide without an operator, as her pipeline does by construction.

ch · lineage

What she carried over, and what she changed

The two codebases are not strangers. Part of “the Lossless side” is her work, and part of hers restates ours. The arc is the most interesting finding of the study: the data model she designed in June is not what Instant Deck runs. What it runs is closer to how dididecks decks are actually made, and she arrived there by building the simpler path, measuring it, and reversing it.

  1. 2026-06-07LosslessData models written for hercontext-v/models/ added because “a collaborator is designing a remote database and has been guessing at shapes”. An exploration the same day records “slide = row in a database” against “slide = .astro component file” and proposes a hybrid.
  2. 06-08 to 06-09phoenixcapShe commits a SvelteKit shell into dididecks-aiapps/frontend/ (308 files, an in-memory mock backend), packages/shared/ and a frontend/backend split document.
  3. 2026-06-20phoenixcapA Codex knowledge packThe dididecks model restated as build briefs, with schemas, a SQL blueprint, drift rules and status templates.
  4. 2026-08-24phoenixcapInstadeck’s main beginsAn import of two earlier repos.
  5. 2026-08-25phoenixcapDeckSpec plus a deterministic compilerProposed, built offline, left “disabled and unmounted”: the same hybrid our June exploration proposed, reached separately.
  6. 2026-09-23bothInstant Core, reversedPR 40 simplified the pipeline; PR 47 restored “the DidiDecks-style authoring kernel”. The same day, context-v and changelog were adopted.
  7. 2026-09-29phoenixcapMemory productized; a spec of record“refactor: productize creative memory” removes context-v and changelog in favour of operation-scoped database records. The Instant Deck spec of record is written.
Ideadididecks-aiKnowledge pack (June)Instadeck (September)
Scroll and Play as coupled implementations“Naming is fuzzy here” in CLAUDE.mdCarried over: “coordinated implementations, not the same implementation rendered twice”Changed: one render path, whole-deck HTML proven in Chromium
Review matrix, no “vacuous ready”DeckMatrix; “vacuous-Ready bug fixed”Carried over almost word for wordChanged: a visual scorecard and a conformance ledger
Status taxonomySitemap status disciplineCarried over: Draft, Implementing, Partially-Shipped, ShippedChanged: Implemented, Partial, Not proven
People and companies as data/data-assets/* routes, crawl-fetch-ingestCarried overChanged: “real people remain real” as an acceptance check
Gated access to private decksReader gating per deck siteCarried overChanged: author accounts and workspaces
Frontend and backend splitHer architecture doc inside dididecks-aiCarried overBuilt: SvelteKit plus FastAPI on Railway
StorageFilesystem as databaseChanged: “a database-backed deck operating system”Postgres, records per operation
Business fieldsNoneNew: blocks bound to persistent fields, rebuild jobsNot in Instant Deck’s canonical path
Authoring methodHolistic first, Markdown narratives, DESIGN.mdNot in the packRe-converged: the Markdown document chain and 06-DESIGN.md
Memorycontext-v, changelogs, prior sessionsNot in the packChanged on purpose: operation-scoped database records
AgentsClaude Code, skillsCodex prompts, one at a timeCodex for dev; OpenAI for the product; 19 product SKILL.md

Carried over into the June pack: the Scroll and Play split, the review matrix, the status taxonomy, data assets, gated access, the front-end and back-end split. Changed by September: one render path, author accounts, Postgres. Re-converged after PR 47: Markdown per slide, a design contract per deck, whole-deck reasoning first.

ch · the four comparisons

Shared, similar, different, missing, by layer

Every artifact from both inventories sits in exactly one row, and no row pairs across layers: 25 rows in the developer layer, 17 in the in-product layer.

Shared

dev 3 of 25 · product 2 of 17

Few, because the two sides use different tools and stacks. The interest is in how each is used.

Developer layer

READMEs on both sides route the reader elsewhere quickly: hers to product/, with a release-safety rule; ours to the specs, the splash, the client sites and the skills snapshot. Ours has drifted: it calls a mock-backed shell “active”.

Agent scratch kept out of git. Both ignore the coding agent’s local folder. Hers also ignores /docs and /scripts by default, force-adding only the records she wants tracked, and labels Bitácora logs not product or agent context: an explicit line between notes and record that ours doesn’t draw.

Deploy config. Hers carries policy in the config (API startup must not race migration); ours is small because static sites need little.

In-product layer

Agent Skills as domain know-how. Both use SKILL.md for craft rather than plumbing: hers for VC analysis and slide craft (ic-critique, why-now), ours for brand, design contract, ingest and imagery. Hers are short (271 lines for 19) and imperative; ours are long and explain why.

Chromium as the judge of a slide. Hers proves every render before publication and measures geometry and asset visibility. Ours drives a running site to PNG, SVG, PDF, PPTX and Keynote, and the Play-UI rule (No responsive CSS. No JS in the slide itself) exists so export is faithful. Hers uses the browser to check; ours uses it to produce.

Ledger rows: shared
IDInstadeckdididecks-ai
D-SH1README.mddididecks-ai/README.md
D-SH2.gitignore: .codex*, /.local-work/, Bitácora logs.gitignore: .claude/; context-v/extra/ (gitignored)
D-SH3railway.toml for API, worker, renderer, frontendvercel.json (root and client sites), package.json, pnpm-workspace.yaml, pages.yml
P-SH119 product SKILL.md files (AI-VC analyst)Deck skills: theme-system, maintain-design-md, crawl-fetch-ingest, generate-consistent-og-images, overlay-svg-text
P-SH2Chromium proof and rendererpackages/deck-export (Playwright), the Play print route, SlideCanvas

D- rows are the developer layer, P- rows the in-product layer. Rows with several files are trimmed to their gist.

Similar

dev 10 of 25 · product 8 of 17

Same job, different form. Both layers are dominated by this bucket, which fits a shared lineage.

Developer layer

Instruction files. Both built three levels: hers root, backend/ and frontend/; ours anchor, ai-labs and dididecks-ai. Hers contradicted itself, so she removed it from main and wrote a shorter reset pinned by a test. Ours contradicts itself differently, with stale skill paths. Ours orients a cold agent in one read, including why; hers can’t silently drift.

Specs. Her spec of record has a precedence order for authority, change control, a conformance ledger rating each requirement Implemented, Partial or Not proven, and a definition of done. Our main spec is a north-star document, still Draft. Ours keeps questions open while the product is being discovered across engagements; hers closes them so an agent can’t reopen them by accident. Hers costs earlier reasoning, which survives only on archive branches; ours costs an agent knowing what has been decided.

Decision records. Her dated records open by saying what they do not authorize: not approved for merge, not deployment authorization. Ours record reasoning and loose ends. Her PR 39 recovery note is a candid account of a reversal.

Living maps, runbooks, session memory. Our sitemap has a file per route with typed frontmatter; her runtime inventory says it does not claim browser acceptance. Our browser-drive blueprint is tree-wide; her live runbook is stricter: Do not call the release complete unless the command exits zero. Her Bitácora stays close to the operator and out of every agent’s context; our changelog is shared, searchable, and read by the deck agent.

Briefs for a builder, a mirror image. We wrote data models so she “stops guessing at shapes”; she wrote a Codex pack to brief Codex on the dididecks model. These documents were the real interface between the two silos. Git: hers makes a change reviewable as a unit; ours makes the reasoning readable in git log. Coding agent: Codex and Claude Code; neither side’s artifacts are tied to its tool.

In-product layer

The Markdown document chain, the strongest convergence. Hers: 01-source.md through 06-DESIGN.md, then slides/sNN.md, each creative source plus typed front matter. Ours: narrative files with typed frontmatter and a 592-line DESIGN.md for one client. Hers adds earlier stages as named files, hashes and evidence IDs; ours keeps files across weeks of iteration and many variants. Her spec names a principle we never wrote down: Markdown is not factual authority … Strong typing is required at safety/execution boundaries.

The generator. Hers is a service that runs unattended for any customer at any hour, in a large file that is hard to load. Ours can do anything Astro can render, and needs an operator for every change. The contract: her canonical prompt is fixed per release and customer-safe (default intent: Make this deck much better.); ours is a method an operator adapts per client, and it explains its reasons.

Spec row to component. In June our exploration proposed a structured spec row compiled deterministically into a component. In August her prompt-system decision proposed a DeckSpec plus a deterministic compiler and left it unmounted. Both reached the same hybrid separately; neither has made it the main path.

Judgement, knowledge, diligence. Her visual audit scored slides on eight dimensions, once; our rank pill records a four-state verdict per slot, continuously. Her knowledge is broad and pre-written (195 files); ours is narrower and grows from engagements. Her Due Diligence findings stay off the investor slides; our citation popover keeps sources one click away on the slide.

Ledger rows: similar
IDInstadeckdididecks-ai
D-SI1AGENTS.md at root, backend/, frontend/ (to 09-29); a shorter reset set on a branch../AGENTS.md, ai-labs/CLAUDE.md, dididecks-ai/CLAUDE.md (dev facet)
D-SI2product/ spec of record, genesis, surface specscontext-v/specs/ (6), the business-model exploration, client-site specs
D-SI3Offline foundation, render-repair plan, plan.mdcontext-v/plans/ (15); chroma-decks plans (3)
D-SI4Pre-merge decision, recovered-fix audit, PR39 recovery, prompt-system decisionExplorations, reminders (2), blueprints (2)
D-SI5Runtime inventorycontext-v/sitemap/ (29), FILEMAP.md, maintain-filemap loop
D-SI6Live acceptance runbook, audit and acceptance runners (dev facet)Browser-drive verification blueprint, the browser-drive block in CLAUDE.md
D-SI7Bitácora (tracked to 09-18, now local)changelog/ (17); calmstorm-decks (21), chroma-decks (7)
D-SI8Codex knowledge pack: prompts, HOW_TO_USE_WITH_CODEX.mdcontext-v/models/ (9), architecture/, apps/frontend/docs/ (the last two authored by phoenixcap)
D-SI9About 70 single-purpose branches, PRs to #64, 34 of 329 commits with bodiesgit-conventions; development → main → master; 111 commits, 99 Claude co-author trailers
D-SI10Codex as the coding agentClaude Code, skills via ~/.claude/skills
P-SI1Spec (canonical prompt, stage contracts), instant_deck_mvp_policy.pydeck-iteration-workflow; CLAUDE.md “Scroll-UI vs. Play-UI”
P-SI2Prompt packages (nine), typed stage catalogue (about 30 roles)slide-target; setup-new-dddecks-workspace (stub)
P-SI3working_documents.py, redesign_documents.py, source_design_review.pyClient narratives (17 for calmstorm) and DESIGN.md (592 lines)
P-SI4full_html_generation_service.py (10,982 lines)Claude Code under the deck skills, plus apps/deck-shell
P-SI5llm_knowledge/ (195 files)corpus submodule (27 slide archetypes); client data/; /data-assets/* routes
P-SI6Prompt-system decision (DeckSpec plus compiler), offline foundationBridging-PLG exploration (spec row compiled to a component); /api/slide-decompose
P-SI7Seven-primitive visual auditSlideRankPill, DeckMatrix, data/audits/slides.json, /api/slide-rank
P-SI8Due Diligence runtime and non-blocking warningsDD-ready citation spec; shell citation popover

D- rows are the developer layer, P- rows the in-product layer. Rows with several files are trimmed to their gist.

Different

dev 8 of 25 · product 2 of 17

On one side only, where the choice fits that side’s context, so nobody should “fix” it.

Developer layer

Repo memory as product memory, refused, the deliberate counter-choice of the study. Hers makes easier: customer runs can’t be steered by operator notes; memory is per customer and typed; a new agent can’t mistake history for authority. Harder: development reasoning lives in PR titles, dated docs and a local log, so a cold agent has less to read. Ours makes easier: one place for both kinds of memory, cheap to add, readable by any agent, compounding across clients. Harder: an agent can treat an old exploration as current, and nothing separates a client’s confidential notes from the method.

Hers: release paperwork for migrations and four services against customer data; patch transport through CI as a workaround for her agent environment; pivots kept as archive branches. Ours: pseudomonorepo rules, the shared skills library, the corpus and publishing, which exist because of seven client repos inside a 27-project tree.

In-product layer

Where the generator’s memory lives. Her knowledge loader excludes operator notes from every product knowledge lane; our generator reads the client folder, because it is the operator’s agent. Where generation will run, the deepest strategic difference: our spec bets on a local-first native app with embedded Claude chat, because the paying user won’t open a terminal and confidential material stays local; hers bets on a hosted web app. Ours keeps the agent’s flexibility and moves it closer to the user; hers keeps the user’s simplicity and constrains the agent.

Ledger rows: different
IDInstadeckdididecks-ai
D-DF1Test that forbids context-v/ and changelog/ (adopted 09-23, removed 09-29); Bitácora boundary testcontext-vigilance and changelog-conventions themselves
D-DF2Deployment gate, rollback record—
D-DF3Patch transport through CI—
D-DF4Archive branches—
D-DF5—Pseudomonorepo rules: branch tiers, the relocation hard stop, submodule bumps
D-DF6—Shared skills library, Stow linking, the in-repo snapshot
D-DF7—Chroma corpus over context, changelogs and past sessions
D-DF8—Publishing frontmatter, splash/
P-DF1Loader excludes operator logs; operation-scoped memoryBy design, the generator’s context is the repo
P-DF2—Embedded Claude chat in a local-first native app (planned); cloud-workspace spec

D- rows are the developer layer, P- rows the in-product layer. Rows with several files are trimmed to their gist.

Missing

dev 4 of 25 · product 5 of 17

On one side only, where the other could borrow it. Eight of nine run toward us, and all of those concern verification.

Developer layer (all on our side)

CI that runs tests, and tests at all. The shell has shipped at least four versions to seven consumers with typecheck as the only automated check; her one workflow runs about 27 test files with no paid calls. Tests that pin documents: hers assert that the spec and genesis still say what they must, and that the spec’s prompt equals the runtime prompt; we rely on discipline and frontmatter. A review packet, headed unfinished implementation. Do not merge or deploy this snapshot: low priority, but it matters when someone else picks up unfinished work.

Drift noted in dididecks-ai (not fixed here): CLAUDE.md lists two submodules where there are seven client sites and a corpus, and an old skills path; a README claim about a mock; architecture links to files that don’t exist; five skills in the snapshot differ from the anchor, and one isn’t linked anywhere a session can load it; a filemap last regenerated 2026-06-07.

In-product layer

On our side, the main lesson of this layer. A frozen, provider-free corpus of past passes and failure shapes, where we have 51 exported slides and nothing that checks a shell change against them. Acceptance runners with 11 conditions, where ours is a human walk-through. Measured failure, then a bounded repair, at exactly the Play-UI step CLAUDE.md calls hardest. Tests that keep the runtime prompt equal to the spec, where our equivalent, the skill pack, has drifted.

On her side, a flow from ours. Variants side by side. Her genesis names the problem: Sometimes the LLM produced an excellent redesign. Sometimes it produced generic layouts. Her answer is constraint and measurement around one result per run; ours is optionality, every slot with several variants ranked by a human. Since her §21.2 acceptance is a human judgement, two or three treatments for the weakest slides would give it something to choose between. The cost is paid model calls, which her spec guards.

Ledger rows: missing
IDInstadeckdididecks-ai
D-MI1CI workflow running testsMissing (only pages.yml)
D-MI2backend/tests/ (platform half)Missing (typecheck only)
D-MI3Spec pin test; instruction-contract test (branch)Missing
D-MI4Independent review packetMissing
P-MI1docs/evidence/, frozen corpus.v1.json, agent regression servicesMissing
P-MI2Live acceptance (11 conditions), acceptance runnersMissing
P-MI3Render-repair design, repair skills chosen from measured failuresMissing
P-MI4LLM-machinery tests, prompt pinMissing
P-MI5Missing: one result per runVariants kept side by side per slot

D- rows are the developer layer, P- rows the in-product layer. Rows with several files are trimmed to their gist.

ch · insights and recommendations

Insights and recommendations

Each item is labelled by layer and framed as something one side could borrow from the other. Neither column is a verdict on the other product.

For Lossless

Insights

  1. Product layer We never wrote down what “good” means for a deck. Her spec does: a result “must be materially better than the original deck … not merely valid, complete, or render-safe.” Our design principles describe the job without defining success or failure.
  2. Product layer Our “prompt” is our skill pack, and it has drifted. Her test keeps the prompt of record and the runtime prompt identical. Our snapshot exists to keep collaborators in sync and is out of sync in five places.
  3. Product layer The step we call hardest is the one we don’t measure. Play-UI conversion is where CLAUDE.md says Claude is “bad”. Her pipeline shows how to make that step self-checking: measure the render, name the failure, repair only what failed.
  4. Product layer She validated our method by trying to leave it. PR 40 simplified the pipeline; PR 47 restored “the DidiDecks-style authoring kernel”. Markdown per slide, a design contract, whole deck first: a silo under different pressure kept all three.
  5. Product layer She stated the principle behind our narratives. Markdown for creative coordination, strong types only at safety boundaries (spec §8), and a rule against overbuilding: prove the Markdown can’t hold it before adding a schema.
  6. Dev layer Context without checks drifts. dididecks-ai gives an agent more orientation than her repo does, and has more drift: a stale submodule list and skill path, a README claim about a mock, broken architecture links, a four-month-old filemap.
  7. Dev layer Our status lines say what’s done, not what’s withheld. “Not approved for merge”, “not deployment authorization”: cheap lines that stop an agent treating a plan as permission.
  8. Dev layer The real interface between our silos was translation documents. We wrote context-v/models/ for her; she wrote a Codex pack from ours. The pattern is worth naming in context-vigilance.
  9. Both layers Our dev harness is our product harness, and that is a choice with a cost. Because Claude Code generates the decks, everything in context-v is potential generator input. Her wall makes the cost visible: we have no line between method, history and a client’s confidential notes.

Recommendations, ranked by payoff

  1. Product layer Pin the deck skill pack. A check that fails when a skill in the dididecks-ai snapshot differs from the anchor copy, or retire the snapshot and link instead. Upstream setup-new-dddecks-workspace and link it. From her spec-and-prompt pin test. effort S
  2. Product layer Write a quality invariant, an acceptance contract and a conformance ledger into the deck spec. Name what counts as failure (“only reformatted”), what evidence counts as acceptance, and mark each requirement Implemented, Partial or Not proven. From her spec §2.1, §21, §22. effort S
  3. Dev layer A first CI for dididecks-ai. Typecheck the shell and frontend, run the skill-pack check, build one client site against the local shell. From her one CI workflow. effort S
  4. Product layer A render-proof tier in deck-export. For each Play-UI slide at 1920×1080, fail on overflow, clipping, missing assets and off-canvas elements, and write a diagnostic an agent can act on. Later, map failure shapes to repair instructions. From her render-repair plan and repair skills. effort M
  5. Product layer A frozen slide corpus. Snapshot a few dozen shipped Play-UI slides with their render metrics, and run the render-proof tier against them when the shell changes. From her provider-free corpus.v1.json. effort M
  6. Product layer Name the document chain. Add the early stages as files per engagement (source notes, research, investor story, redesign plan) ahead of the narratives and DESIGN.md, and state that Markdown is creative coordination, not factual authority. From her working documents and spec §7–8. effort M
  7. Dev layer Say what a doc does not authorize. One line under the title of plans and explorations: “plan only”, “not approved to ship”. From her gate and pre-merge records. effort S
  8. Both layers Draw a line between method, history and client-confidential notes in what the deck agent reads, with a precedence order like hers (“Git history … as historical evidence only”). From her genesis doc, spec §1 and boundary test. effort S
  9. Dev layer A pruning pass on dididecks-ai drift, in its own session. Prompted by her reset of AGENTS.md, by contrast. effort S

Most come from her product layer, where her harness is deep and ours is thin on measurement. Two come from her developer layer, where her verification habits run deeper; one crosses layers.

For Instadeck

Insights

  1. Dev layer main has no front door for a coding agent right now. Since 09-29 an agent starting on main gets README.md and product/, which say a lot about what and little about how to work in the repo. The reset set exists, is shorter, and is pinned by a test.
  2. Dev layer The “why” of development has thinned out. With changelog/ removed and the Bitácora local, the checked-in reasons for a change are mostly in dated docs/ and PR titles; 34 of 329 non-merge commits have a body. Thin for the next agent or collaborator.
  3. Dev layer Two workflows look active and aren’t. They sit under frontend/.github/ and backend/.github/, where GitHub doesn’t look, and call scripts that no longer exist.
  4. Dev layer Layered instruction files need a rule for which level wins. The old set contradicted itself on the default provider and where to push. Tests now keep the reset honest; ours need the same rule.
  5. Product layer The product harness kept the creative method. It keeps what made the original workflow work, and the acceptance contract and conformance ledger say “Not complete” where something isn’t.
  6. Product layer The last mile of acceptance is a human, and the verdict has no home. §21.2 needs three live decks judged by a person; §22 records “No current evidence”. Our in-place rank pill is a small, continuous way to capture that verdict per slide.
  7. Product layer One result per run makes every run carry the whole quality risk. Your genesis names inconsistency as the reason the product exists. A second treatment for the weakest slides turns inconsistency into choice.
  8. Product layer The wall, and the door you left in it. Spec §12 keeps a bounded, provenance-bearing design memory (prior DESIGN.md artifacts, redesign decisions). That is the part of our context-v that compounds across clients.

Recommendations, ranked by payoff

  1. Dev layer Land the reset instruction set on main, with its test. Merge the three short AGENTS.md files, or just the root one, and add a “read these first” list in order and a short “why we work this way” paragraph for the rule an agent is most likely to break. Worked example: dididecks-ai/CLAUDE.md, minus its tree rules and skills lists. effort S
  2. Dev layer Move or delete the two nested workflows. Move them to the root .github/workflows/ with paths: filters for frontend/** and backend/**, and fix or drop the missing scripts. Worked example: dididecks-ai pages.yml, scoped with paths: [splash/**]. effort S
  3. Dev layer Put the “why” in squash-merge bodies. A pull-request template with three headings (Why, Evidence, What this does not authorize). Squash merges carry the body into main, without reviving changelog/. Worked example: the body structure in git-conventions. effort S
  4. Product layer Give the human verdict a home. A per-slide verdict on a published DesignVersion (four states plus a note), stored with lineage, and a ledger row in §22 that counts verdicts from the three-deck acceptance runs. Worked example: the shell’s slide-rank route and the slide-audit data model. effort M
  5. Product layer Offer a second treatment for the weakest slides. After Chromium proof, generate one alternate for the two or three weakest slides from the same 06-DESIGN.md and slide document, and let the user pick. Count it against the run budget; off by default for paid runs. Worked example: a client site’s variant registry and the DeckMatrix view. effort M

Five on purpose, ranked by payoff for one repo with two apps, one product owner and many Codex sessions. Each is the smallest version that helps.

ch · method and sources

Method and sources

This is a collaboration study: one collaborator’s codebase beside ours, read both ways, as described in the exploration Explore Collaborator Codebases for Insights: Comparative Highlights, including its section “Two harnesses, not one”. It ran in three steps.

  1. Harness evidence. An inventory of every sign of how Instadeck is built with coding agents and how its own agents produce decks, read at one commit (2026-10-02; 364 commits on main, 1,453 tracked files), each artifact tagged dev, product or both.
  2. Compare and contrast, by layer. dididecks-ai, two of its client sites, ai-labs and the anchor layer inventoried on our side, then every artifact sorted into one bucket within its own layer.
  3. This page, built only from those two steps, on 2026-10-03. No finding here is new.

Named, not linked. This page names phoenixcap, Instadeck and dididecks-ai. It does not link to her repository or to the study notes.

Limits. The Chroma server was down during the comparison, so our corpus of past sessions is described, not queried. Five of dididecks-ai’s seven client sites and its corpus submodule were not read.

Diagrams. The harness maps, loops and shape diagram were authored as Archify sources from the comparison’s Mermaid, validated, and re-themed with this site’s tokens. The layer map and the lineage timeline are hand-built HTML.

↑ Back to contents · ← All studies