Skip to content

Plan 45: design at the adopter's scale: install from a commit, a bundle that fits, corpus rules, and the Spec Studio's phase 0 - #33

Merged
darko-mijic merged 43 commits into
mainfrom
feature/design-at-scale-v0
Oct 15, 2026
Merged

darko-mijic merged 43 commits into
mainfrom
feature/design-at-scale-v0

Conversation

@darko-mijic

@darko-mijic darko-mijic commented Oct 13, 2026 •

Copy link
Copy Markdown
Contributor

This PR carries plan 45: design at the adopter's scale. The first adopter, libar-platform, designs a Convex transactional domain platform as about 240 Specs in six Packs, most of it design that will stay ahead of its code for months. This chunk unlocks the Protocol for that work. An adopter installs from a commit. A design pass fits a large Pack into a model's budget. A corpus runs its own policy inside sdp validate. And a person reads a Pack's design on a static page: the Spec Studio's phase 0 (plan 42 was its brief). The platform moved onto this branch in its own pull request, libar-platform#13, which pins this head.

Read this first. The owner asked for as much of the platform's design work as possible to be unlocked, and delegated the rulings while away. Every ruling is in the second table under Decisions and rulings, and each is a candidate to overturn before merge. One question is the owner's alone and blocks nothing here: whether the Studio replaces the platform's committed Pack page (its decision 58), and how a reviewer holding only a link reaches the Studio's pages.

Why

A read of the platform, its feedback and this repository's backlog found four needs, in order:

  1. Reach main cheaply. The platform pinned 822aea4 through a vendored tarball, so about fifteen of its asks, delivered here since, were out of reach.
  2. Design passes that fit a budget. The context bundle (recipe 36) returned only its header for every platform Pack: pack:history-view needed at least 299,106 UTF-16 units against a default budget of 100,000, most of it repeated locations and declarations carried twice.
  3. A page a person can read. The platform's reviewers read carrier files, because the Markdown Pack page is a wide table.
  4. The platform's rules inside sdp validate. The platform's gate, design/tools/check.py, parsed carriers to check citation edges, isolation between contexts and its readiness policy, outside the one graph.

What it introduces

Install from a commit. The package builds itself through prepare, so an adopter pins github:libar-dev/software-delivery-protocol#<sha> and re-pins with one edit. The README teaches the approvals npm and pnpm need, by git source and never by name alone. npm run check:git-install installs a committed revision with npm and pnpm, from a clone and from a git archive, and requires sdp --version to name the exact commit. A GitHub install builds from an archive with no .git, so the commit now travels through export-subst. → spec:consumers.adopter-on-ramp, spec:consumers.engine-provenance

The design loop at the adopter's scale.

  • The context bundle carries each member's file once, an open question only in questions, a pinned value only in its Design section, and a cut entry as its address or { line }. A new footing cut comes second, and declarations: "addresses" opts into a last cut that keeps pinned declarations as their entry addresses. pack:history-view now fits in 93,806 units. → spec:consumers.context-bundle
  • Recipe 41, the key-family register, lists every Design and UI entry whose key starts with a prefix, across the corpus, a Pack or a list of Specs, with no row cap. It turns the platform's 109 limit*, 27 error* and 80 table*/index* entries into registers. → spec:consumers.agent-surface.register-recipes
  • Every recipe declares the parameter names it takes. A name it does not take replaces the answer with { unknownParams, accepts }, so recipe 30 given spec no longer answers for its built-in sample. → spec:consumers.agent-surface.recipe-parameters

Corpus checks. Three Specs designed, built and grouped in pack:corpus-checks-v1, each with examples that execute.

  • sdp validate --rules PATH [--params FORM]... runs a corpus's own policy: one sdp q body per file, over its own copy of the graph and report, returning { findings }. Each --params belongs to the --rules before it. Corpus findings print in their own section, name their rule and rules file, never move a readiness floor, and fail the run like a Protocol error. --watch reads the rules again each cycle. → spec:validation.corpus-rules
  • Recipe 42, the architecture walk, checks forbidden layer pairs and isolated contexts over the anchored uses edges. A recipe that returns findings is a rules file as shipped, so --rules dist/recipes/42-the-architecture-walk.js runs it under validate. → spec:validation.architecture-constraints
  • Recipe 43 compares component designs, the Specs that state a component before its code, with the component anchors that later realize them. → spec:model.planned-architecture

The Spec Studio, phase 0. sdp studio publishes a static page set under generated/spec-studio/: an index with task routes, one page per Pack and per Spec, and a search page. The pages open from file:// with no network and read in full without script, except search. Every link resolves inside the page set, two runs give the same bytes, and the repository's projection suite certifies it as a fifth root. A Pack page leads with a summary the graph computes, then the framing and one closed card per member, each with its rung, floor, questions and bindings in words. Six custom elements enhance the pages, with no framework and no build step on the adopter's side. Search shares one matcher with g.findByConcept, shipped for browsers as the ./concept-match subpath. The design pass split the Studio into child Specs so the code satisfies whole Specs; a hand-built prototype on real data was reviewed and then deleted once the real pages replaced it. → pack:spec-studio-v1, with publisher, pack-page, search and page-elements

Smaller things.

  • A prose mention inside a rule, flow or question now carries its line. → spec:validation.prose-mentions
  • The Vitest adapter awaits a world's after hook whether its steps pass or fail. → spec:extraction.example-runner#rule.worldCleanup
  • check-carrier-rule.mjs is deleted: it still demanded a sentence the Pack syntax ruling retired. pack:self-hosting-v1 again holds every self-hosted Spec, as its framing says.
  • The vault (spec:consumers.obsidian-vault) is ruled its own projection, not the Studio's local half, and waits for a reader.
  • The three skills, AGENTS.md, the README and the recipe catalog teach all of the above.

See it

The Studio is new, so there is no base view; the four frozen projections did not change. These are the pages at the head, from file://. How these were made.

The platform's history-view Pack. The summary first, then the framing and the member cards:

The platform's history-view Pack page

A question with its fields, and search finding OD-157, a decision register id the platform wrote into that question:

A Spec page's open questions

Search for OD-157

This repository's own pack:corpus-checks-v1, every member stated and derived ready:

The corpus-checks Pack page

The same Pack page at 390 pixels, an example page and the index are in the assets folder. No human view yet shows a declaration beside the assertion that checks it, run results, or the vault.

The first adopter on this branch

libar-platform#13 pins this head and passes its whole CI checks job on it:

  • package.json pins github:libar-dev/software-delivery-protocol#abf532d…, this branch's head, with the approvals the README teaches; sdp --version names that commit, and the vendored tarball is gone. The platform's CI (checks and native) passes on it.
  • decisions.py and the page scripts run the shipped dist/recipes/ files with --params instead of cutting bodies out of the catalog.
  • The graph-side half of check.py (readiness policy, mentions, address resolution, cycles, citation edges, question sources, isolation) now runs as design/rules/policy.js and recipe 42 under sdp validate --rules. Every planted mistake its tests carry still fails the gate.
  • npm run studio publishes the platform's 251 pages, and the gate checks they build deterministically. The committed Pack page stays: see Feedback wanted.
  • Two associations: OD-157 in its question's text, and a test anchor binding the type-comparison suite to the eleven Specs whose declarations it compares.

The reader-task acceptance. A gpt-6-astra job given only the platform's page set, with no repository and no CLI, worked plan 42's five tasks:

Task From the pages Where
Find the history contract Yes Pack page, then history-projection's Contract and Design sections, #design.typeHistoryProjection
Locate OD-157 Yes Search, then history-rebuild#question.verifyPassUnderPause
Explain the aggregate dependency Yes "Rested on by" on the Pack page, then aggregate-projection's relations and its blocking question
Find one declaration's type comparison In part The page names the suite and its file and line; no page shows the assertion for one declaration
Native-backend evidence for a paused-rebuild example Yes: none recorded The example's Verification section names the tier; its Bindings say no verifier and no run result

Self-hosted and graph-measured

The design diff (recipe 35) from 7eef29b, the arc's base: 16 Specs added, 24 changed, none removed; 3 Packs changed (one added); 28 Specs whose bindings changed. Pack design (recipe 29) at the head:

Pack Members Held below next rung Waiting only for the author Entries · pinned Open questions With implementation
pack:corpus-checks-v1 13 0 0 23 · 11 0 3
pack:spec-studio-v1 18 1 7 81 · 20 3, none blocking 8

The Studio Pack's seven waiting members are the Studio's parent and the Specs that carry its deferred panels, which stay below ready until a reader needs them. The held one, the lenses, waits on the verification panels and the runtime overlay. Re-run the recipes rather than inheriting these numbers.

Decisions and rulings

The owner's direction for this chunk, on 2026-10-13:

Direction Where it landed
Schedule as much work as possible to unlock the platform's design work, avoiding excess complexity plan 45, its lanes and its deferrals
Do any work the platform repository needs; build what the Protocol lacks first Lane E, and the Protocol fixes it found (the GitHub install's commit)

Delegated to the main thread, with cross-family reviews as advisers (gpt-6-sol, Opus 5.5, Fable 5.1); each awaits the owner's review:

Ruling Carrying Spec
An adopter installs from a commit through prepare; no npm prerelease while the version is 0.0.0 adopter-on-ramp
A build from an archive records its commit through export-subst engine-provenance
Pinned declarations may be cut to entry addresses, opt-in; a partial bundle stays refused; a cut entry without an address keeps only { line } context-bundle
The key-family register is one recipe and needs no model change; an unresolved Pack member is a diagnostic register-recipes
A parameter name a recipe does not take replaces the whole answer with { unknownParams, accepts } recipe-parameters
A rules file is one sdp q body returning { findings }; a rule id is one kebab token; a finding's file is a root-relative POSIX path corpus-rules
Each --params belongs to the --rules before it; each file gets its own copy of the graph; one file named twice is refused, through a symlink too corpus-rules
validate exits 1 on any Protocol error, corpus error or failed rules file; under --watch a rules file is reread each cycle, and editing one starts no cycle corpus-rules
The rules runner lives in the CLI; the validation layer holds only the corpus finding types corpus-rules
The architecture walk's provisional answers stand: it runs as a recipe and as a rules file architecture-constraints
Choosing a provider stays prose; one runtime owner per concern is a corpus rule; an empty uses is stated none; an absent anchor is realizedLayer: "absent" planned-architecture
A corpus-checks Pack holds the three Specs and their examples pack:corpus-checks-v1
The Studio publishes static pages that read without script, except search; elements only enhance; phase 0 has no AI slices spec-studio
Search lives on one page, indexes only the graph, and shares findByConcept's matcher, shipped as ./concept-match search
A Pack page leads with its summary, folds the holds into it, and gives each card one colored badge pack-page
A keyed question shows its key with a copy action for its address; example-space owners show only on Pack and Spec pages spec-page.core, shell
The fifth reader task passes when the reader finds whether a verifier is bound spec-studio
The Studio joins the projection suite; element tests run under Node with no DOM library publisher
The vault is its own projection, not the Studio's local half, and waits for a reader obsidian-vault
ready stated for corpus rules, architecture constraints, planned architecture, their ten examples, and the Studio's data, shell, search, publisher, index, Pack page, Spec page core and page elements; defined for the Studio's lenses, Spec page, components and responsive layout each Spec; recipe 9 cleared the floor first

No row is added to the decision registry: none of these passes the three-part test on its own, and each lives in its carrying Spec.

How it ran

Three waves, each lane in its own worktree, each reviewed by a model of another family and fixed before the main thread merged it. gpt-6.1-sol built; Opus 5.5 designed and reviewed; gpt-6-sol and Fable 5.1 reviewed. Wave 1 built the install path and the loop at scale and designed corpus checks and the Studio, with a prototype Pack page. Wave 2 built corpus checks and the Studio, moved the platform onto the engine, and brought the self-hosting oracle to green. Wave 3 pinned the platform to the published branch, retired its graph-side checks into rules files, and ran two adversarial reviews and Astra's acceptance. The reviews' findings that held were fixed with tests that failed first: recipe 43 missing a design id in a double-backtick span, a rules file run twice through a symlink, an absolute finding path, recipe 41 throwing on an unresolved Pack member, a bundle cut dropping an address before a full stop, docs naming four projection roots, and the GitHub install's unknown commit.

Review on the PR

Greptile ran the code and found three defects, each fixed in abf532d with a test that failed first:

  • Watch could not finish stopping (P1). Ctrl+C during a rules body that awaits a live handle left validate --watch --rules running, and the next rules file could still run. An operator stop during a rules run now ends the process with exit 0 and no further output → spec:consumers.validate-watch#rule.operatorStop.
  • Key searches missed Specs (P2). A Spec whose only match was a coined key (verify pass against verifyPass) was dropped; it is now a result.
  • Search repeated section walks (P2). Each record's authored-text lookup is built once per search instead of once per entry; a property-read count proves it (16,512 reads for 128 entries before, under 256 after).

CodeRabbit skipped this PR: it changes more files than its limit.

Try it

git switch feature/design-at-scale-v0 && npm ci && npm run build

# The Studio: open generated/spec-studio/index.html
node dist/cli/sdp.js studio . --exclude explorations --exclude examples --exclude test/fixtures/import/parity
# Wrote …/generated/spec-studio (286 files)

# A corpus rule: the architecture walk as a rules file
node dist/cli/sdp.js validate . --exclude explorations --exclude examples --exclude test/fixtures/import/parity \
  --rules dist/recipes/42-the-architecture-walk.js --params '{"forbidden":[{"from":"domain","to":"edge"}]}'
# validate: 0 errors · 6 warnings (conformance + honesty over the one graph)
# corpus rules: 0 errors · 0 warnings · 0 of 1 files failed (the corpus's own rules)

# A key family, and a name a recipe does not take
pnpm --silent sdp:q "$(cat dist/recipes/41-the-key-family-register.js)" --params '{"prefixes":["walk"]}' --json
# { "totals": { "rows": 6, "specs": 1, "byPrefix": { "walk": 6 } }, … }
pnpm --silent sdp:q "$(cat dist/recipes/30-design-change-impact.js)" --params '{"spec":"spec:consumers.reader"}' --json
# { "unknownParams": ["spec"], "accepts": ["specs"] }

In an adopter: pin github:libar-dev/software-delivery-protocol#abf532d9a2a5da536d9235215f108d6aaa723ca2 with the README's approvals, then npx sdp --version.

Measured at close

At abf532d, re-measured at close; re-run the recipes rather than inheriting these. The links and screenshots above are pinned to e1d941d, the head before Greptile's review.

  • npm run check passes: 2,199 pooled tests and 100 CLI tests.
  • validate: 276 Specs · 6 Packs · 339 anchors → 621 nodes · 1,624 edges; 0 errors, 6 warnings (five intended prose mentions and one pending verifier gap, both pinned by the oracle).
  • Stated readiness: 245 ready, 17 defined, 3 scoped, 11 idea. The drift alarm (recipe 2) is empty.
  • The open-question register (recipe 20): 43 questions on 24 Specs, 16 blocking (8 deferrals with triggers, 8 holds), none malformed.
  • On the platform at its pin: 243 Specs, 0 errors, 12 warnings; corpus rules 0 of 2 files failed; recipe 36 on pack:history-view with declarations: "addresses" fits in 93,806 of 100,000 units.

Feedback wanted

  • The platform's decision 58. Should the Studio become the page a design pass reads first, replacing the committed Markdown Pack page? And how should a reviewer holding only a link reach the Studio: a CI artifact, a preview URL per pull request, or the committed page meanwhile? Lane E kept the committed page until you rule.
  • The Pack page's summary. Sentences, each opening with its count, or a small table? Open as spec:consumers.spec-studio.pack-page#question.summaryFormat.
  • Astra's three asks, most important first: say "no native run evidence shown" near the top of an executable example's page; link each pinned declaration to the assertion that checks it; and read "Rests on" and "Rested on by" as "This Pack depends on" and "Depends on members of this Pack".
  • Corpus rules in practice. The platform's rules file still copies address resolution and cycle search, because a rules file cannot call them. A reader verb, or findings answers from recipes 25 and 26?

Upcoming

1. Merge, with libar-platform#13, once the owner has read the delegated rulings. The platform re-pins to the merge commit or keeps this head, which stays reachable.

2. Next PR: the platform designs ahead of its code, and the Studio follows the reader. A proposal.

Lane What Why now
Rules-file reach Address resolution and cycle search a rules file can call, as a reader verb or findings answers from recipes 25 and 26, ruled in a short design pass The platform's rules file keeps copies of both
Component designs The platform states the components of layers 3 to 6 as component designs, and recipe 43 compares them as the code arrives Recipe 43 is built and has nothing to compare yet on either corpus
Studio for a link A page set per pull request, as a CI artifact or a preview URL, with the stamp file Decision 58 waits on it
A declaration's comparison From a pinned declaration to the assertion that checks it The one reader task met only in part
The large Packs application and foundation still exceed the bundle's budget after every cut; read them through perspectives (recipe 37), or cut the verifier rows example members repeat A design pass on either needs it

Re-entry: both PRs merged, and the owner's review of the delegated rulings.

3. Statements waiting for the owner, no code needed. Their floor already allows a higher rung: spec:consumers.graph-first-planning (stated scoped, floor ready); spec:consumers.impact-graph, spec:consumers.intent-composition and spec:consumers.edit-model (stated defined, floor ready); and the Studio parents that stay defined until their deferred panels have a reader.

Still deferred, with triggers (recipe 20): the gen-1 .feature import adapter, exhaustive symbol reach, the vault, roadmap views, the reference projection, structural Mermaid, the runtime overlay, and the superseded-decision signal; plan 45 adds watching rules files, exporting sdp q's evaluator, and run evidence for the Studio's verification panels.

Refused, and staying refused:

  • A per-unit satisfies that moves built work into the build backlog; a partial-realization delivery fact.
  • A rung stated by tooling, or a review recorded as a graph fact.
  • A deferral as a sentence inside a ready rule.
  • A count, date or plan number inside a Spec.
  • Reshaping a frozen projection beyond what its Spec already promises.
  • A corpus rule that moves a readiness floor, or a Protocol finding a corpus can silence.
  • Agents writing to .omo/.

🤖 Generated with Claude Code

RetriggerConfidence Score: 4/5

Do not merge until the watch-stop defect is fixed. The two search concerns are non-blocking.

Findings

  1. P1 Watch cannot finish stopping ▶
  2. P2 Key searches miss Specs ▶
  3. P2 Search repeats section walks ▶

T-Rex evidence

CLI stop capture without the changed watch dispatch

  • Ran an isolated bundle copy with the pre-change watch dispatch and sent SIGINT, showing exit 0 within about 10 ms.

CLI stop capture with an active hanging rule on prepared head

  • Sent SIGINT during the actual prepared CLI's rule await and later released the operation, showing five seconds without exit and continued rule execution after stop.

CLI stop capture after rules completed on prepared head

  • Ran the prepared CLI with the same rules configured to complete and sent SIGINT, showing prompt exit 0 when no rule await was active.

Focused CLI verification execution record

  • Captured the executed harness command, runtime, commit, bundle hashes, and subprocess results, showing all focused assertions passed.

Source ranges and watch-dispatch diff used for verification

  • Captured setup instructions, numbered source ranges, the prepared bundle path, and the candidate diff, showing the exact implementation inspected.

Production integrity check after CLI verification

  • Checked production diffs and the prepared CLI hash after execution, showing production files and the prepared bundle remained unchanged.

Executed command-capture script

  • Executed this shell script to capture source inspection, run the focused harness, and check integrity, providing the reproducible verification commands.

Executed subprocess verification harness

  • Executed this harness to launch three CLI flows, send signals, measure exits, and assert post-stop behavior, providing the actual test logic.

Executed rule with a referenced handle and externally released await

  • The CLI executed this rule body with a live interval and unresolved Promise, reproducing an active asynchronous operation that survives SIGINT.

Executed follow-up rule used to detect work after stop

  • The CLI executed this second rule after external release of the stopped cycle, demonstrating that subsequent rule execution was not cancelled.

Isolated corpus fixture used by the CLI flows

  • Copied this carrier into the isolated corpus for each execution, allowing real CLI extraction and validation without regenerating root outputs.

Executed isolated CLI bundle with pre-change watch dispatch

  • Executed this generated copy of the prepared bundle with only the candidate dispatch reversed, providing a same-command comparison without modifying production.

▶ Base revision without Studio search

  • Entered the same query in the isolated fixture without a Studio bundle, matching the base revision’s lack of this feature; no search custom element is registered.

Base fixture with the spaced key query

  • Captured the base-scope fixture with `verify pass` entered and no registered search-results element; this establishes feature absence rather than prior working search.

▶ Shipped search finds the literal key but drops its spaced query

  • Ran the shipped elements with `verifyPass`, then held the `verify pass` failure and runtime diagnostics on screen; the token-matching entry is omitted from results.

Shipped search reports no hits for verify pass

  • Captured the failing query alongside the fixture and observed matcher results; entryMatches is true while searchRecords and rendered result cards are empty.

Chromium and matcher assertion output

  • Recorded the executed validation command, working directory, exit code, control result, and failing-query observations; all reproduction assertions passed.

Source ranges and unchanged production check

  • Executed the source inspection script and captured numbered source, absent base Studio paths, and an empty tracked diff; the failure is localized without production edits.

Full Chromium validation source

  • Executed this complete harness to serve isolated fixtures, load shipped elements, assert matcher behavior, and record both revisions’ scope; the reproduction is repeatable.

Validation command and output capture script

  • Executed this shell wrapper to run the browser harness with a timeout and capture its actual exit code and output; the validation completed successfully.

Source inspection command script

  • Executed this script to print relevant numbered source and check base paths and tracked changes; the recorded source supports the identified admission mismatch.

Isolated base-scope browser fixture

  • Loaded this one-record page without a Studio bundle to reflect the base revision; it provides the same fixture and query scope for comparison.

Isolated shipped-search browser fixture

  • Loaded this one-record page with the shipped custom elements and matcher diagnostics; the numeric camelCase design key reproduces F2.

Executed source matcher bundle

  • Bundled the unchanged source matcher exports and invoked them inside Chromium on the fixture; direct results expose the entry-to-record inconsistency.

Shipped Studio JavaScript used in Chromium

  • Copied the existing shipped browser bundle into the isolated artifact scope and loaded it unchanged; the actual custom element reproduces the missing result.

Shipped Studio styling used by the fixture

  • Copied and loaded the existing shipped stylesheet for both browser fixtures; captures retain Studio styling without rebuilding shared outputs.

Command output from the check

  • Ran an isolated bundle copy with the pre-change watch dispatch and sent SIGINT, showing exit 0 within about 10 ms.

Command output from the check

  • Sent SIGINT during the actual prepared CLI's rule await and later released the operation, showing five seconds without exit and continued rule execution after stop.

Command output from the check

  • Ran the prepared CLI with the same rules configured to complete and sent SIGINT, showing prompt exit 0 when no rule await was active.

Command output from the check

  • Captured the executed harness command, runtime, commit, bundle hashes, and subprocess results, showing all focused assertions passed.

Command output from the check

  • Captured setup instructions, numbered source ranges, the prepared bundle path, and the candidate diff, showing the exact implementation inspected.

Command output from the check

  • Checked production diffs and the prepared CLI hash after execution, showing production files and the prepared bundle remained unchanged.

Evidence from the check

  • Executed this shell script to capture source inspection, run the focused harness, and check integrity, providing the reproducible verification commands.

Evidence from the check

  • Executed this harness to launch three CLI flows, send signals, measure exits, and assert post-stop behavior, providing the actual test logic.

Evidence from the check

  • The CLI executed this rule body with a live interval and unresolved Promise, reproducing an active asynchronous operation that survives SIGINT.

Evidence from the check

  • The CLI executed this second rule after external release of the stopped cycle, demonstrating that subsequent rule execution was not cancelled.

Evidence from the check

  • Copied this carrier into the isolated corpus for each execution, allowing real CLI extraction and validation without regenerating root outputs.

Evidence from the check

  • Executed this generated copy of the prepared bundle with only the candidate dispatch reversed, providing a same-command comparison without modifying production.

Before: F2 01

  • What the screen looked like at this point in the check.

▶ f2-01-before.webm

  • The flow T-Rex ran, recorded end to end.

After: F2 02

  • What the screen looked like at this point in the check.

▶ f2-02-after.webm

  • The flow T-Rex ran, recorded end to end.

Before: F3 Search Cost 01

  • What the screen looked like at this point in the check.

▶ f3-search-cost-01-before.webm

  • The flow T-Rex ran, recorded end to end.

After: F3 Search Cost 02

  • What the screen looked like at this point in the check.

▶ f3-search-cost-02-after.webm

  • The flow T-Rex ran, recorded end to end.

▶ Recording of the check

  • Entered the same query in the isolated fixture without a Studio bundle, matching the base revision’s lack of this feature; no search custom element is registered.

Base fixture with the spaced key query

  • Captured the base-scope fixture with `verify pass` entered and no registered search-results element; this establishes feature absence rather than prior working search.

▶ Recording of the check

  • Ran the shipped elements with `verifyPass`, then held the `verify pass` failure and runtime diagnostics on screen; the token-matching entry is omitted from results.

Shipped search reports no hits for verify pass

  • Captured the failing query alongside the fixture and observed matcher results; entryMatches is true while searchRecords and rendered result cards are empty.

Command output from the check

  • Recorded the executed validation command, working directory, exit code, control result, and failing-query observations; all reproduction assertions passed.

Command output from the check

  • Executed the source inspection script and captured numbered source, absent base Studio paths, and an empty tracked diff; the failure is localized without production edits.

Evidence from the check

  • Executed this complete harness to serve isolated fixtures, load shipped elements, assert matcher behavior, and record both revisions’ scope; the reproduction is repeatable.

Evidence from the check

  • Executed this shell wrapper to run the browser harness with a timeout and capture its actual exit code and output; the validation completed successfully.

Evidence from the check

  • Executed this script to print relevant numbered source and check base paths and tracked changes; the recorded source supports the identified admission mismatch.

Evidence from the check

  • Loaded this one-record page without a Studio bundle to reflect the base revision; it provides the same fixture and query scope for comparison.

Evidence from the check

  • Loaded this one-record page with the shipped custom elements and matcher diagnostics; the numeric camelCase design key reproduces F2.

Evidence from the check

  • Bundled the unchanged source matcher exports and invoked them inside Chromium on the fixture; direct results expose the entry-to-record inconsistency.

Evidence from the check

  • Copied the existing shipped browser bundle into the isolated artifact scope and loaded it unchanged; the actual custom element reproduces the missing result.

Evidence from the check

  • Copied and loaded the existing shipped stylesheet for both browser fixtures; captures retain Studio styling without rebuilding shared outputs.

View artifacts

Summary

Adds commit-based installation, smaller context bundles, corpus rules under sdp validate, and the first static Spec Studio pages.

  • Adopters can install a reviewed commit and see which commit was built.
  • Design recipes fit larger scopes and report when callers pass names they do not take.
  • Corpus rules run through sdp validate and report their own findings.
  • Recipes compare planned components with anchors and check architecture rules against uses.
  • The Spec Studio publishes linked pages for Packs, Specs, and search.
  • The example adapter awaits cleanup, and the retired carrier-rule checker is removed.

Acknowledgments from darko-mijic: pnpm installation checks run only when pnpm is present; git takes precedence over archive metadata; rules-file edits do not start watch cycles; run evidence, declaration-to-assertion links, hosted previews, and whole bundles for the largest Packs are deferred.

Reviews (1) · Last reviewed commit: "close: plan 45 executed, the Pack summar..." · Reviewed by Greptile

darko-mijic and others added 30 commits October 13, 2026 14:08
The next chunk unlocks the Protocol for the first adopter's design work:
installing from a commit, a design-pass loop that fits a large corpus,
corpus checks and planned architecture, and the Spec Studio's phase 0,
with plan 42 as that lane's brief. The plan records the rulings made at
its start on the owner's delegation.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Folds the ruled answers on corpus rules, architecture constraints and
planned architecture into rules and keyed Design entries: the rules file
and its answer, sdp validate --rules and --params, the corpus section and
summary line, exit codes, recipe 42 (the architecture walk) and recipe 43
(planned against realized components). Adds unbound example Specs for
each, groups the three Specs and their examples in pack:corpus-checks-v1,
and deletes the answered nextPacks question.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Lane L's design pass for plan 45, Specs only.

- spec:consumers.context-bundle: a compact bundle. Each member and example
  row names its file once, a cut entry keeps only its line, each entry sits
  in one place, footing cuts to ids, and declarations: "addresses" opts in
  to a last cut of pinned declarations to their entry addresses. The
  declarationCut question is answered and deleted.
- spec:consumers.agent-surface.register-recipes: recipe 41, the key-family
  register, over Design and UI keys only.
- spec:consumers.agent-surface.recipe-parameters: a name a recipe does not
  take is answered as { unknownParams, accepts }, from a declared list each
  body opens with.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Studio's design pass. Six child Specs carry the static page set so its code can satisfy
whole Specs: the publisher, search, the index, the Pack page, the Spec page's core and the
page elements. The shell and the data Spec now describe only what that page set builds.

Every provisional answer on the Studio's Specs becomes a rule or a keyed entry and its question
is deleted, as plan 45's rulings delegate; the questions without one that the page set needs
(header fields, rung colors, schema bindings, UI stories) are answered the same way. Phase 0
holds no AI slice. The vault is a projection of its own and waits for a reader.

The data, element, verb and stamp contracts are keyed Design entries, pinned where two lanes
must agree on a shape.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
One hand-written page, opened from file:// with no request and no build step, rendered from
recipe 29's answer and the Pack context for pack:design-management-v1 here and for the first
adopter's pack:history-view. Custom elements without a framework open cards and copy
locations. The README names the commands that regenerate the inputs, what the design pass took
from the page, and the two associations the adopter's re-pin applies for the five reader tasks.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…h holds it

At the adopter's commit the paused-rebuild examples have no bound verifier, so the fifth reader
task asks the reader to read the binding rather than assert one.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Each --params now belongs to the --rules before it, so the architecture
walk never receives the names another rules file reads and answers them
as unknown. The validate report carries corpusFindings and
corpusFailures; the corpus line stands alone when the graph does not
derive; recipes 42 and 43 answer an unknown name as every catalog recipe
does; matching excludes unreadable designs; uses states none for an
empty list.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The data Spec escapes every `<` in embedded JSON as `<` (it read as a tautology), and the
search index's entries are defined without a term, matching as recipe 23 matches. A finding
whose subject has no page shows on the index only; the search page's `#q=` fragment is exempt
from the element-id check; the Spec page's narrative and sections carry ids that entry hits
link to; and the search page is the one page that needs its script.

The Pack page leads with its summary, each sentence opening with its count, folds the holds
section into the summary, colors only the rung on a card's line, links a question by its key,
splits the card body into citable rules, and says once that the graph records no run. The
prototype follows. Questions left open gain a decider and a provisional reading, and two
deleted questions' reasons are restored.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… rulings

Corpus rules, architecture constraints, planned architecture and eight of
the Studio's Specs state ready; four Studio parents state defined. Plan 45
records the delegated rulings and wave 2's shape.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
darko-mijic and others added 12 commits October 13, 2026 17:16
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…unts, PR 33's screenshots

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Oct 13, 2026 •

Copy link
Copy Markdown

Important

Review skipped

Too many files!

This PR contains 115 files, which is 15 over the limit of 100.

To get a review, reduce the PR to 100 files or fewer by splitting it into smaller PRs or changing its base branch.

Upgrade to a paid plan to raise the limit.

This review couldn't start because sufficient usage credits or metered capacity aren't available. Add credits or update usage-based reviews in the billing tab, then retry.

⚙️ Run configuration
  • Configuration used: Repository YAML (base), Organization UI (inherited)
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: c098670e-3f15-458c-817e-d351131bd6de
📥 Commits

Reviewing files that changed from the base of the PR and between 7eef29b and abf532d.

⛔ Files ignored due to path filters (29)
  • plans/42-spec-studio-phase-zero.md is excluded by !plans/**
  • plans/45-design-at-the-adopters-scale.md is excluded by !plans/**
  • reviews/assets/pr33/README.md is excluded by !reviews/**
  • reviews/assets/pr33/platform-example.png is excluded by !**/*.png, !reviews/**
  • reviews/assets/pr33/platform-pack-phone.png is excluded by !**/*.png, !reviews/**
  • reviews/assets/pr33/platform-pack.png is excluded by !**/*.png, !reviews/**
  • reviews/assets/pr33/platform-question.png is excluded by !**/*.png, !reviews/**
  • reviews/assets/pr33/platform-search.png is excluded by !**/*.png, !reviews/**
  • reviews/assets/pr33/protocol-index.png is excluded by !**/*.png, !reviews/**
  • reviews/assets/pr33/protocol-pack.png is excluded by !**/*.png, !reviews/**
  • test/model.planned-architecture.differing-layer-and-uses.test.generated.ts is excluded by !**/*.generated.*
  • test/model.planned-architecture.matching-design.test.generated.ts is excluded by !**/*.generated.*
  • test/model.planned-architecture.unrealized-design.test.generated.ts is excluded by !**/*.generated.*
  • test/self-hosting-oracle/anchors.ts is excluded by !test/self-hosting-oracle/**
  • test/self-hosting-oracle/consumers.ts is excluded by !test/self-hosting-oracle/**
  • test/self-hosting-oracle/declared-relations.ts is excluded by !test/self-hosting-oracle/**
  • test/self-hosting-oracle/extraction.ts is excluded by !test/self-hosting-oracle/**
  • test/self-hosting-oracle/index.ts is excluded by !test/self-hosting-oracle/**
  • test/self-hosting-oracle/model.ts is excluded by !test/self-hosting-oracle/**
  • test/self-hosting-oracle/pack-members.ts is excluded by !test/self-hosting-oracle/**
  • test/self-hosting-oracle/structural-edges.ts is excluded by !test/self-hosting-oracle/**
  • test/self-hosting-oracle/validation.ts is excluded by !test/self-hosting-oracle/**
  • test/validation.architecture-constraints.forbidden-layer-pair.test.generated.ts is excluded by !**/*.generated.*
  • test/validation.architecture-constraints.isolated-context-as-rule.test.generated.ts is excluded by !**/*.generated.*
  • test/validation.architecture-constraints.unstated-layer-unclassified.test.generated.ts is excluded by !**/*.generated.*
  • test/validation.corpus-rules.copies-contain-changes.test.generated.ts is excluded by !**/*.generated.*
  • test/validation.corpus-rules.error-finding-fails.test.generated.ts is excluded by !**/*.generated.*
  • test/validation.corpus-rules.malformed-finding-fails.test.generated.ts is excluded by !**/*.generated.*
  • test/validation.corpus-rules.warning-finding-informs.test.generated.ts is excluded by !**/*.generated.*
📒 Files selected for processing (115)
  • .agents/skills/sdp-agent-surface/SKILL.md
  • .agents/skills/sdp-authoring/SKILL.md
  • .agents/skills/sdp-sessions/SKILL.md
  • .git-archive-commit
  • .gitattributes
  • .github/workflows/ci.yml
  • AGENTS.md
  • CONTEXT.md
  • README.md
  • check-carrier-rule.mjs
  • check-git-install.mjs
  • contract-dependent-suites.mjs
  • docs/agent-surface/recipes.md
  • examples/checkout-v1/README.md
  • package.json
  • projection-suite.mjs
  • specs/consumers/adopter-on-ramp.sdp.md
  • specs/consumers/agent-surface.answer-shapes.sdp.md
  • specs/consumers/agent-surface.example-space-coverage.sdp.md
  • specs/consumers/agent-surface.recipe-parameters.sdp.md
  • specs/consumers/agent-surface.register-recipes.sdp.md
  • specs/consumers/context-bundle.sdp.md
  • specs/consumers/engine-provenance.sdp.md
  • specs/consumers/graph-first-planning.sdp.md
  • specs/consumers/obsidian-vault.sdp.md
  • specs/consumers/spec-studio.components.sdp.md
  • specs/consumers/spec-studio.data.sdp.md
  • specs/consumers/spec-studio.index-page.sdp.md
  • specs/consumers/spec-studio.intent-panel.sdp.md
  • specs/consumers/spec-studio.lenses.sdp.md
  • specs/consumers/spec-studio.pack-page.sdp.md
  • specs/consumers/spec-studio.pack.sdp.md
  • specs/consumers/spec-studio.page-elements.sdp.md
  • specs/consumers/spec-studio.publisher.sdp.md
  • specs/consumers/spec-studio.responsive.sdp.md
  • specs/consumers/spec-studio.sdp.md
  • specs/consumers/spec-studio.search.sdp.md
  • specs/consumers/spec-studio.sharing.sdp.md
  • specs/consumers/spec-studio.shell.sdp.md
  • specs/consumers/spec-studio.spec-page.core.sdp.md
  • specs/consumers/spec-studio.spec-page.sdp.md
  • specs/consumers/spec-studio.verification-panels.sdp.md
  • specs/consumers/validate-watch.sdp.md
  • specs/corpus-checks.pack.sdp.md
  • specs/extraction/example-runner.sdp.md
  • specs/model/planned-architecture.differing-layer-and-uses.sdp.md
  • specs/model/planned-architecture.matching-design.sdp.md
  • specs/model/planned-architecture.sdp.md
  • specs/model/planned-architecture.unrealized-design.sdp.md
  • specs/self-hosting.pack.sdp.md
  • specs/validation/architecture-constraints.forbidden-layer-pair.sdp.md
  • specs/validation/architecture-constraints.isolated-context-as-rule.sdp.md
  • specs/validation/architecture-constraints.sdp.md
  • specs/validation/architecture-constraints.unstated-layer-unclassified.sdp.md
  • specs/validation/corpus-rules.copies-contain-changes.sdp.md
  • specs/validation/corpus-rules.error-finding-fails.sdp.md
  • specs/validation/corpus-rules.malformed-finding-fails.sdp.md
  • specs/validation/corpus-rules.sdp.md
  • specs/validation/corpus-rules.warning-finding-informs.sdp.md
  • specs/validation/prose-mentions.sdp.md
  • src/adapters/vitest.ts
  • src/cli/build-args.ts
  • src/cli/build-artifacts.ts
  • src/cli/build-command.ts
  • src/cli/corpus-rules.ts
  • src/cli/output.ts
  • src/cli/params.ts
  • src/cli/q-command.ts
  • src/cli/sdp.ts
  • src/cli/studio-command.ts
  • src/cli/validate-view-command.ts
  • src/cli/validate-watch.ts
  • src/projections/studio/data.ts
  • src/projections/studio/pages/code-spans.ts
  • src/projections/studio/pages/frame.ts
  • src/projections/studio/pages/html.ts
  • src/projections/studio/pages/index-page.ts
  • src/projections/studio/pages/index.ts
  • src/projections/studio/pages/pack-page.ts
  • src/projections/studio/pages/search-page.ts
  • src/projections/studio/pages/spec-page.ts
  • src/projections/studio/pages/text.ts
  • src/projections/studio/paths.ts
  • src/projections/studio/publish.ts
  • src/projections/studio/studio.css
  • src/reader/concept-match.ts
  • src/reader/reader.ts
  • src/studio-elements/copy.ts
  • src/studio-elements/dom.ts
  • src/studio-elements/expander.ts
  • src/studio-elements/filter.ts
  • src/studio-elements/index.ts
  • src/studio-elements/search-results.ts
  • src/studio-elements/search.ts
  • src/studio-elements/stamp.ts
  • src/validate/contracts.ts
  • src/validate/validators.ts
  • test/architecture-recipes.test.ts
  • test/check-self-hosting-gates.test.ts
  • test/cli.test.ts
  • test/concept-match.test.ts
  • test/corpus-rules.test.ts
  • test/entry-locations.test.ts
  • test/iteration-recipes.test.ts
  • test/package-smoke.test.ts
  • test/recipes.test.ts
  • test/self-hosting-corpus-checks.test.ts
  • test/self-hosting-graph.test.ts
  • test/skills.test.ts
  • test/studio-data.test.ts
  • test/studio-elements.test.ts
  • test/studio-pages.test.ts
  • test/studio-publisher.test.ts
  • test/vitest-adapter.test.ts
  • tsup.config.ts

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Comment thread src/cli/validate-watch.ts
Comment on lines +578 to +581
const outcome =
parsed.rules === undefined
? runValidate(parsed, output, "validate", hooks)
: await runValidateRules(parsed, output, hooks);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Watch cannot finish stopping

validate --watch --rules waits for the active rules body even after Ctrl+C. The stop handler closes the watcher and wakes its idle wait, but does not end await runValidateRules(...). If a body hangs on an async operation that keeps Node alive, the command stays running instead of exiting 0. When that operation eventually completes, the next rules file can still execute after the stop.

Fix this before merging: stopping must terminate active rule execution and its live handles, and prevent further rules or output after the stop.

Artifacts

CLI stop capture without the changed watch dispatch

  • Ran an isolated bundle copy with the pre-change watch dispatch and sent SIGINT, showing exit 0 within about 10 ms.

CLI stop capture with an active hanging rule on prepared head

  • Sent SIGINT during the actual prepared CLI's rule await and later released the operation, showing five seconds without exit and continued rule execution after stop.

CLI stop capture after rules completed on prepared head

  • Ran the prepared CLI with the same rules configured to complete and sent SIGINT, showing prompt exit 0 when no rule await was active.

Focused CLI verification execution record

  • Captured the executed harness command, runtime, commit, bundle hashes, and subprocess results, showing all focused assertions passed.

Source ranges and watch-dispatch diff used for verification

  • Captured setup instructions, numbered source ranges, the prepared bundle path, and the candidate diff, showing the exact implementation inspected.

Production integrity check after CLI verification

  • Checked production diffs and the prepared CLI hash after execution, showing production files and the prepared bundle remained unchanged.

Executed command-capture script

  • Executed this shell script to capture source inspection, run the focused harness, and check integrity, providing the reproducible verification commands.

Executed subprocess verification harness

  • Executed this harness to launch three CLI flows, send signals, measure exits, and assert post-stop behavior, providing the actual test logic.

Executed rule with a referenced handle and externally released await

  • The CLI executed this rule body with a live interval and unresolved Promise, reproducing an active asynchronous operation that survives SIGINT.

Executed follow-up rule used to detect work after stop

  • The CLI executed this second rule after external release of the stopped cycle, demonstrating that subsequent rule execution was not cancelled.

Isolated corpus fixture used by the CLI flows

  • Copied this carrier into the isolated corpus for each execution, allowing real CLI extraction and validation without regenerating root outputs.

Executed isolated CLI bundle with pre-change watch dispatch

  • Executed this generated copy of the prepared bundle with only the candidate dispatch reversed, providing a same-command comparison without modifying production.

View artifacts

T-Rex Ran code and verified through T-Rex

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in abf532d: spec:consumers.validate-watch#rule.operatorStop now says an operator stop during a rules run ends the process with exit 0, and the watcher does so. No further rules file runs and nothing more is written. A process test with a live interval and a never-settling promise, plus a second rules file that would print, failed first (exit bound exceeded, second file ran) and now passes.

Comment thread src/studio-elements/search-results.ts Outdated
Comment on lines +98 to +99
if (record.entries.some((entry) => entry.key?.toLowerCase().includes(needle)))
matchedIn.push("key");

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Key searches miss Specs

searchRecords drops matches that entryMatches accepts. A Spec with design: { verifyPass: 42 } matches the entry search for verify pass, but this check tests whether verifypass contains verify pass. If no other field contains the phrase, the page says no node matches.

This is a non-blocking search gap: readers must know the exact joined key to find that Spec. Keep nodes with matching coined-key entries and add a test through searchRecords, not only entryMatches.

Artifacts

▶ Base revision without Studio search

  • Entered the same query in the isolated fixture without a Studio bundle, matching the base revision’s lack of this feature; no search custom element is registered.

Base fixture with the spaced key query

  • Captured the base-scope fixture with `verify pass` entered and no registered search-results element; this establishes feature absence rather than prior working search.

▶ Shipped search finds the literal key but drops its spaced query

  • Ran the shipped elements with `verifyPass`, then held the `verify pass` failure and runtime diagnostics on screen; the token-matching entry is omitted from results.

Shipped search reports no hits for verify pass

  • Captured the failing query alongside the fixture and observed matcher results; entryMatches is true while searchRecords and rendered result cards are empty.

Chromium and matcher assertion output

  • Recorded the executed validation command, working directory, exit code, control result, and failing-query observations; all reproduction assertions passed.

Source ranges and unchanged production check

  • Executed the source inspection script and captured numbered source, absent base Studio paths, and an empty tracked diff; the failure is localized without production edits.

Full Chromium validation source

  • Executed this complete harness to serve isolated fixtures, load shipped elements, assert matcher behavior, and record both revisions’ scope; the reproduction is repeatable.

Validation command and output capture script

  • Executed this shell wrapper to run the browser harness with a timeout and capture its actual exit code and output; the validation completed successfully.

Source inspection command script

  • Executed this script to print relevant numbered source and check base paths and tracked changes; the recorded source supports the identified admission mismatch.

Isolated base-scope browser fixture

  • Loaded this one-record page without a Studio bundle to reflect the base revision; it provides the same fixture and query scope for comparison.

Isolated shipped-search browser fixture

  • Loaded this one-record page with the shipped custom elements and matcher diagnostics; the numeric camelCase design key reproduces F2.

Executed source matcher bundle

  • Bundled the unchanged source matcher exports and invoked them inside Chromium on the fixture; direct results expose the entry-to-record inconsistency.

Shipped Studio JavaScript used in Chromium

  • Copied the existing shipped browser bundle into the isolated artifact scope and loaded it unchanged; the actual custom element reproduces the missing result.

Shipped Studio styling used by the fixture

  • Copied and loaded the existing shipped stylesheet for both browser fixtures; captures retain Studio styling without rebuilding shared outputs.

View artifacts

T-Rex Ran code and verified through T-Rex

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in abf532d: a Spec whose only match is a coined-key entry is kept (#rule.entryHits now says so), and each record's authored-text lookup is built once per search instead of per entry. Tests through searchRecords and a property-read count (16,512 reads for 128 entries before, under 256 after) failed first.

Comment thread src/studio-elements/search-results.ts Outdated
Comment on lines +57 to +70
function isStringEntry(record: SearchRecord, entry: SearchEntry): boolean {
if (entry.section === "narrative") return true;
const walk = (value: unknown, path: string | null): boolean => {
if (typeof value === "string") return path === entry.entry && value === entry.text;
if (Array.isArray(value))
return value.some((item: unknown, i) => walk(item, `${path ?? ""}[${String(i)}]`));
if (typeof value === "object" && value !== null) {
return Object.entries(value).some(([key, item]: [string, unknown]) =>
walk(item, path === null ? key : `${path}.${key}`),
);
}
return false;
};
return walk((record.sections as Record<string, unknown> | undefined)?.[entry.section], null);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Search repeats section walks

isStringEntry walks the section again for every entry being searched, making search work grow roughly quadratically on every keystroke. The shipped search element took about 2.2 seconds per input event with a test section containing 4,000 string entries; search completed, but typing was delayed.

This is a non-blocking performance concern for large design sections. Record whether an entry holds authored text when building the index, or build a path lookup once, rather than rediscovering its type for every search.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

T-Rex Ran code and verified through T-Rex

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in abf532d: a Spec whose only match is a coined-key entry is kept (#rule.entryHits now says so), and each record's authored-text lookup is built once per search instead of per entry. Tests through searchRecords and a property-read count (16,512 reads for 128 entries before, under 256 after) failed first.

@darko-mijic
darko-mijic merged commit 5a0b22c into main Oct 15, 2026
3 checks passed
@darko-mijic
darko-mijic deleted the feature/design-at-scale-v0 branch October 15, 2026 04:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant