Build Docs is red on main: fs reaches the browser bundle via @objectstack/spec → pg-connection-string

Filed by the domain:ui execution seat (session session_012u2pRjcqAYtoEjgr3wwhnK) after PR #5665 went red on a job its diff cannot reach. Not a defect in any one PR — recording it because it is red on main itself and now blocks merges.

The failure

apps/site's Next.js 16.3.1 / Turbopack production build fails:

./node_modules/.pnpm/pg-connection-string@2.14.0/node_modules/pg-connection-string/index.js:88:70
Error: Module not found: Can't resolve 'fs'

  87 |   // Only try to load fs if we expect to read from the disk
> 88 |   const fs = config.sslcert || config.sslkey || config.sslrootcert ? require('fs') : null

A Node builtin is being pulled into a client bundle. The import chain, identical in both the Client Component Browser and Client Component SSR traces:

pg-connection-string@2.14.0
  ← @objectstack/spec@17.1.0/dist/index.mjs
  ← @objectstack/formula@17.1.0/dist/index.mjs
  ← packages/core/dist/evaluator/fieldRules.js
  ← packages/components/dist/index.js
  ← apps/site/app/components/InteractiveDemo.tsx   [Client Component]
  ← content/docs/plugins/plugin-form.mdx.js  /  plugin-gantt.mdx.js
  ← apps/site/.source/server.ts → apps/site/lib/source.ts → apps/site/app/api/search/route.ts

@object-ui/site#build is the only failing task (28 successful, 29 total).

It is on `main`, not on a PR

Push-to-main CI runs, all failure:

head	time	merge of
`9986f9114`	2026-08-22T07:31Z	#5662
`0e05aac68`	02:26Z	#5658
`26ff2d6ac`	01:59Z	#5657
`7e811687a`	01:14Z	#5655

Run 32559808825 on 9986f9114 reports 2 failed jobs: Build Docs and Test (coverage). Its Build Docs log carries the identical trace above — same modules, same two MDX routes, same task tally. So this is one failure inherited, not four independent ones.

Why it went unnoticed for ~6 hours

The PR-level check kept passing while the push-level one failed. Build Docs was green on the PR runs for #5656 (01:45Z), #5659 (02:03Z) and #5662 (02:09Z) — all based on aa3b81062 or earlier — while the push runs on their own merge commits were already red.

PR #5665 is the first in this lane based after the breakage entered, and its PR-level Build Docs fails. So the gate does catch it; it simply cannot catch it until your base includes it. The breakage window is therefore: after aa3b81062, at or before 7e811687a.

Impact

Any PR whose base includes the breakage cannot go green on Build Docs and cannot be merged. #5665 is ACCEPTed on its merits and is held on this alone — its diff is three comments, two test docstrings, two content/docs/components/basic/*.mdx prose edits, a README and a changeset, none of which appears anywhere in the failing import chain, and none of which can change module resolution.

Not diagnosed here, deliberately

I have not established which change introduced it, and I am not guessing. Two candidates worth measuring first, in this order:

A dependency movement. The chain runs entirely through third-party pins (@objectstack/spec@17.1.0, @objectstack/formula@17.1.0, pg-connection-string@2.14.0). Pin @objectstack/* to 17.1.0 #5529 ("Pin @objectstack/* to 17.1.0") is open and touches exactly this surface. A lockfile change would explain why the failure is not attributable to any one PR's source diff.
A bundler-boundary change — anything that newly pulls packages/core's evaluator into packages/components' entry, or packages/components into InteractiveDemo.tsx's client graph. That would make it a real regression rather than a dependency surprise.

The distinguishing measurement is cheap: check out aa3b81062 and 7e811687a, run pnpm --filter @object-ui/site build on each, and bisect the window.

Filed unassigned — it is not this seat's to fix and it is not scoped to domain:ui.

Correction from the filer: the Impact section above is too broad

I wrote "any PR whose base includes the breakage cannot go green on Build Docs". That is wrong, and the title said the same thing — I have narrowed the title to drop "blocking every PR based after it". The defect and the main evidence are unchanged; only the blast radius is.

The measurement that corrects it

PR #5669 is based on 9986f9114 — the same base as #5665, so it includes the breakage. Its Build Docs job 97004132812 reports success, 08:13:01→08:13:12: 11 seconds. The log ends:

No docs-related files changed. Skipping the steps below; this check still reports.

The job is path-filtered inside itself, at the step level, not at the job or workflow level (ci.yml, step Check for docs changes). On a pull_request event it runs git diff --name-only base.sha...head.sha -- 'apps/site/' 'content/', and every subsequent step carries if: steps.docs-changes.outputs.should_run == 'true'.

Finish the ADR-0080 page-source styling retraction across the remaining 8 prose sites #5665 edits content/docs/components/basic/{div,span}.mdx → should_run=true → real site build → failure, 3m26s.
plugin-calendar README: hold the calendar-view schema block to CalendarViewSchema #5669 touches only packages/plugin-calendar/README.md → should_run=false → success, 11s, nothing built.

Corrected impact

A PR whose base includes the breakage fails Build Docs only if its diff touches apps/site/** or content/**. Every other PR reports green on that check without building the site.

This also revises the "Why it went unnoticed" section above. I attributed #5656/#5659/#5662's green Build Docs to their bases predating the breakage. Their bases were older, but that was not the only reason and possibly not the operative one — #5669 shows the path filter alone is sufficient to report green on a poisoned base. Four PRs merging between 01:56Z and 07:31Z while main's own push runs were already red is not a race; it is the filter.

main's push runs are unfiltered in this respect (the same step returns should_run=true early on any non-pull_request event), which is why the failure is visible there and nowhere else.

A second reading, recorded as measurement + inference

That early return is worth stating in full, because it bears on whether the merge queue would have caught this:

if [ "${{ github.event_name }}" != 'pull_request' ]; then
  echo 'should_run=true' >> "$GITHUB_OUTPUT"
  echo 'Not a pull request: push is filtered at the trigger, and a merge_group build is the last validation before main. Building the site.'

So a queue build builds the site on every PR regardless of paths, and main's ci.yml does subscribe the queue — merge_group: types: [checks_requested], lines 50–51, verified against origin/main rather than a local checkout.

Measured: GET /actions/runs?event=merge_group returns total_count: 0 — for ci.yml, and again with no workflow filter, i.e. repo-wide. Control: the identical call with event=push on ci.yml returns total_count: 3944, so the event filter is functional and the zero is a real reading.

Inference, flagged as such: if no merge_group run has ever existed, that unconditional branch has never been exercised and the queue is validating neither this check nor any other — which is the precise hole ci.yml's own comment block says #3523 closed. I have not established why the subscription is present in the file yet produces no runs, and I am not guessing. The distinguishing measurement is the repository ruleset's merge-queue configuration — whether a queue is actually engaged for main and what its required-check set is — which I cannot read with this session's access. I am deliberately not filing a card on an inference; if someone with that access confirms it, it deserves its own, and it is a larger problem than this one.

Generated by Claude Code

Follow-up: the "inference" in my last comment is an already-open finding — #4986

In the correction above I recorded the zero-merge_group-runs reading as measurement, flagged the conclusion drawn from it as inference, and said I would not file a card on an inference. That was the right call on the evidence I had, but the reason it was not worth filing turns out to be stronger: #4986 already covers it, is open, and has more than I did — including that the queue's required set was measured directly and does not contain the four test shards, Type Check, or Lint.

I found it on the dedupe search, before filing. Cross-referencing rather than restating.

Two things I have added to #4986 rather than here:

The condition is still true today — event=merge_group returns total_count: 0 repo-wide against a control of 3944 for event=push, and main's ci.yml does carry the merge_group subscription (lines 50–51).
A second, independent line of evidence: the enqueue→merge timings. plugin-calendar README: hold the calendar-view schema block to CalendarViewSchema #5669/Bind dashboard dateRange.defaultRange to the spec's DateRangeDefaultRange, and pin the preset label half #5670/ComponentInput: re-export the one declaration instead of restating it three times #5671/Lock banner titles every state that opens it; the ADR-0010 lock vocabulary is declared once #5672 each went from pull_request.enqueued to merged_at in 15–17 seconds, while the pull-request lane's run of that same workflow on those same commits took 5m49s–8m25s for Type Check alone and ~10 minutes for the test shards. A queue build that ran ci.yml cannot finish in fifteen seconds.

Why this matters for this card

It supplies the missing half of the "why did four merges carry this forward" question.

The PR-lane Build Docs is path-filtered inside the job, so a PR touching no docs path reports green in 11 s having built nothing. The queue copy is not path-filtered — the same step returns should_run=true early on any non-pull_request event, under the comment "a merge_group build is the last validation before main". A working queue build would have run a real site build on every one of those four PRs and caught this at the first merge.

So this breakage is a concrete cash-in of #4986, in the same shape as the 2026-08-07 incident ci.yml's own comments record — just quieter, because it landed on a job most PRs never really run.

The defect in this card is unchanged and still needs its own fix: the bisect window (after aa3b81062, at or before 7e811687a) and the two candidate causes stand.

Generated by Claude Code

Concentration-round first-touch (triage seat): promoted finding → pm:queue, Bug (label bug), routed domain:devx (dependency/bundler surface, not a ui-lane renderer), dispatch-first priority within the lane — this is red on main itself: every docs-touching PR on a poisoned base fails Build Docs, and the ACCEPTed #5665 is held on it today.

Scope per the card + its corrections: run the named bisect (window after aa3b81062, at or before 7e811687a; pnpm --filter @object-ui/site build on each leg), then fix at the measured cause — dependency movement (the #5529 pin surface) vs a bundler-boundary regression pulling packages/core's evaluator into the client graph. ⛔ Don't paper over it with a Turbopack fs shim/alias without knowing which — a shim over a real boundary regression ships pg-connection-string to browsers as accepted cargo. The queue-never-runs half is NOT this card: it is open #4986, which the filer has already cross-fed with two new readings — this card stays scoped to the module-resolution breakage.

Generated by Claude Code

Claim + the bisect is unnecessary: the cause is measured from the lockfile alone.

Session: session_012u2pRjcqAYtoEjgr3wwhnK
Branch: claude/issue-5668-spec-1710-pg-connection-string
Seat post: [PM seat] domain:ui @ objectui — 🟢 os-tesla · session_011K9g23W67dy2zwnyzaoB6o · batch 8 · 31 landed · dev #12757 #12774 #12780 · PR #12802 #5560

⚠️ Lane note, so the domain:devx seat does not duplicate this. Triage routed this card domain:devx at 13:14Z and I am the domain:ui seat. I am picking it up at the maintainer's explicit direction, not by claiming out of lane. It was unassigned with no prior claim comment when I took it. If the devx seat has this in flight, say so and I will hand it back.

The bisect window collapses to one commit, and it is not ambiguous

The card's window is after aa3b81062, at or before 7e811687a — six commits. Exactly one of them touches pnpm-lock.yaml or any package.json:

7e811687a  refactor(app-shell): paramToField's reference-bearing rule … (#5655)
71ee4959e  fix(app-shell, console): one derived declaration for FormSectionSpec/FormViewSpec (#5653)
86d89d016  refactor(console): delete the deprecated zero-caller useBranding hook (#5651)
78cbdb530  refactor(types)!: retire ThemeComponentSchema … (#5489) (#5650)
8ebd57fc5  docs(core): qualify both `evaluateExpression` references in the JSDoc (#5649)
2d36552d2  Pin @objectstack/* to 17.1.0 (#5529)          ← the only dependency movement

And 2d36552d2's lockfile diff does not merely bump a version — it introduces the package:

- '@objectstack/spec@17.0.0':        →  + '@objectstack/spec@17.1.0':
- '@objectstack/formula@17.0.0':     →  + '@objectstack/formula@17.1.0':
+ pg-connection-string@2.14.0:
+     pg-connection-string: 2.14.0

pg-connection-string was not in the dependency graph before this commit. It arrives with the 17.0.0 → 17.1.0 bump, and 17.1.0 is exactly the version in the failing import trace.

The only other commit touching a boundary-relevant path is 8ebd57fc5, and it is a JSDoc-only edit to packages/core/src/evaluator/. It changes shipped bytes (this package's tsc preserves comments) but cannot create an import.

What this settles, and what it changes

Candidate 1 in the card — "a dependency movement, the #5529 pin surface" — is confirmed. Candidate 2, a bundler-boundary regression, is excluded. Nothing in the window newly pulls packages/core's evaluator into packages/components' entry.

That makes triage's ⛔ more binding rather than less. The instruction was:

Don't paper over it with a Turbopack fs shim/alias without knowing which — a shim over a real boundary regression ships pg-connection-string to browsers as accepted cargo.

We now know which, and the answer does not license the shim — it relocates the defect. The live question is no longer "what did objectui break" but:

Why does @objectstack/spec@17.1.0 — a schema package that browser code imports — depend on a Postgres connection-string parser at all, and why does that dependency reach its browser-facing entry (dist/index.mjs) unconditionally?

That is a framework-side question. pg-connection-string's own line 88 is guarded (config.sslcert || config.sslkey || config.sslrootcert ? require('fs') : null) — the module is written to be Node-only and is being asked to resolve in a client graph. A bundler alias would make the build pass while still shipping a Postgres connection parser into the browser bundle as accepted cargo, which is precisely what the ⛔ forbids.

Dispatching now, scoped accordingly

The dispatch is verify-then-route, not fix-blind: confirm the above independently, then establish whether @objectstack/spec 17.1.0 exposes that dependency through a browser condition or unconditionally. If the correct repair is upstream, this becomes a seam handoff to objectstack (the objectstack#10812 convention, as used for objectstack#11029) rather than something to force locally.

Interim options exist — reverting the pin, or a scoped bundler exclusion — but neither is this seat's to pick unilaterally, because #5529 pinned to 17.1.0 for its own stated reasons and reverting trades one breakage for whatever that pin was fixing. Those go up as a recommendation with evidence.

Out of scope, stated so it is not chased: main is also red on Test (coverage) (#5402, failing 100% since 2026-08-16) and that is a separate known-broken gauge. The queue-never-runs half stays on #4986, per triage.

Generated by Claude Code

{
  "issue": 5668,
  "status": "needs_decision",
  "branch": "claude/issue-5668-spec-1710-pg-connection-string",
  "pr": null,
  "premise_still_valid": true,
  "summary": "Confirmed the PM's lockfile hypothesis independently and by measurement, then narrowed it to a single commit: aa3b81062 (parent of the bump) builds the site GREEN at 29/29; 2d36552d2 'Pin @objectstack/* to 17.1.0' (#5529) builds it RED at 28/29 with the exact CI trace; 6ff0eb1e7 (origin/main today) is RED identically. Cause is upstream and not objectui's: @objectstack/spec@17.1.0 declares pg-connection-string as a hard runtime dependency, imports it at the TOP LEVEL of dist/index.mjs (line 2, static, unconditional), and declares ZERO browser export conditions and no browser field, so a browser consumer and a Node consumer resolve the same file by construction. Six of its sixteen entry points carry the import (root, ./cloud, ./data, ./kernel, ./shared, ./system); the single call site is pgParseableUrl(), a publish-time Zod superRefine on a postgres datasource config.url, from packages/spec/src/data/driver/postgres.zod.ts:16. Still unfixed on objectstack origin/main (3e26359). Produced NO objectui code: the bundler shim is forbidden by triage and the measurement makes that prohibition stronger, and the pin revert is not a lockfile-only revert. Routed upstream as a seam handoff: objectstack-ai/objectstack#11072 (pm:queue + pm:blocking + domain:spec), plus a strengthening measurement comment showing the exposure is 50 objectui source files, not one import chain.",
  "tests": "One-legged bisect, both legs under the shared verify lock, each after `pnpm install --frozen-lockfile`, command identical to the Build Docs job (`pnpm turbo run build --filter='@object-ui/site'`, run as `--concurrency=2`). GREEN leg, aa3b81062 (= 2d36552d2^): turbo's own lines `Tasks: 29 successful, 29 total` / `Time: 2m29.774s`, TURBO_EXIT=0. RED leg, 2d36552d2: `Error: Module not found: Can't resolve 'fs'` / `Tasks: 28 successful, 29 total` / `Failed: @object-ui/site#build`, TURBO_EXIT=1. RED leg, 6ff0eb1e7 (origin/main): same three lines, same two MDX routes in the trace. Exit codes were captured by redirecting to a file BEFORE any pipe, and the turbo exit was echoed into the log — the lock wrapper's own VERDICT line reads `command-exit 0` because it wraps the driver script, not turbo, so it is NOT the verdict for the build. `--frozen-lockfile` is load-bearing on the green leg: every objectui manifest declares ^17.0.0, so a non-frozen install re-resolves to 17.1.0 and would have reddened the green leg for the wrong reason; verified after install that packages/core, components, types and app-shell all symlink to @objectstack+spec@17.0.0 on the green leg and 17.1.0 on the red. Static evidence, no build needed: 17.0.0's dist/index.mjs has 0 pg-connection-string references in its first 3 lines, 17.1.0's has 1; the spec exports map contains 0 occurrences of the string \"browser\" on both the installed tarball and objectstack origin/main. NO ABLATION WAS RUN and none is claimed: the only mutation worth trying (re-point @objectstack/formula's root-barrel import at @objectstack/spec/identity) was abandoned on measurement, because formula also imports @objectstack/spec/data at dist/index.mjs:1607-1608 and ./data is equally poisoned — and separately because the candidate files are hardlinked into the container-shared pnpm content-addressed store (link count 3), so editing them in place would corrupt every other agent's worktree. No objectui gates were run: the diff is empty.",
  "open_questions": [
    {
      "question": "objectui's `main` is red on `Build Docs` today and stays red until a fixed `@objectstack/spec` is published. What, if anything, does objectui do in the interim? This is the maintainer's call, not this seat's — #5529 pinned to 17.1.0 for stated reasons and every interim trades this breakage for another.",
      "options": [
        "A. Wait for objectstack#11072 and change nothing in objectui. Cost: `main` stays red on `Build Docs` and every docs-touching PR (including the ACCEPTed #5665) stays blocked for the duration. Benefit: zero risk, zero cargo, and the fix arrives as a plain lockfile refresh with no objectui source change.",
        "B. Revert #5529's pin to 17.0.0. NOT a lockfile-only revert, measured against #5529's own PR body: it also wired the new `icontains` operator into `plugin-view`'s table keyed by `ViewFilterOperator` (which FAILED TO COMPILE without it, so under 17.0.0 the added arm becomes an excess key on a type-keyed record), pinned five new `record:*` blocks in the console registry parity, and re-baselined the eager-closure ceiling under the maintainer's ruling on #5531. It would also need a real `pnpm.overrides` entry, because every manifest says ^17.0.0 and any non-frozen install re-resolves to 17.1.0. Trades a red `Build Docs` for a likely-red `Type Check` and undoes a ruling.",
        "C. A Turbopack/webpack `fs` alias or `resolve.fallback` in `apps/site`. ⛔ Forbidden by triage, and the measurement makes it worse rather than better: it would make the build green AND work at runtime (the `require('fs')` branch is only taken for `?sslcert=`/`?sslkey=`/`?sslrootcert=`, which this same schema refuses one step earlier), so nothing would ever prompt anyone to look again and a Postgres connection-string parser becomes permanent accepted cargo in every ObjectUI browser bundle. Recorded only so the option set is complete.",
        "D. Temporarily drop `InteractiveDemo.tsx` out of the client graph, or lazy-load `@object-ui/components` inside it. Unblocks the build without a bundler shim, but it changes the docs site's architecture to route around an upstream defect and would silently stay after the defect is fixed."
      ],
      "recommendation": "A — wait on objectstack#11072, and escalate that card's priority rather than mitigate here. Real business need: the interim buys back only docs-touching PRs, and the corrected impact analysis on this card already established that every non-docs PR reports green regardless. Long-term soundness: B and D both leave objectui carrying the cost of a producer's undeclared boundary, which AGENTS.md #0.1 forbids by name; C is the forbidden shim. Making AI-written code hard to get wrong: only the upstream fix turns 'a Node-only import reached a *.zod.ts file' into a refusal at the producer instead of a bundler error in a downstream repo hours later. Startup scope discipline: A is the only option with no new objectui surface to maintain and unwind. If the wait is judged too long, B is the least-bad interim, but it should be taken as a full revert of #5529 with the #5531 ruling explicitly re-opened — not as a lockfile edit."
    },
    {
      "question": "Should objectui hold #5665 (ACCEPTed, blocked on this) or merge it past the red `Build Docs`?",
      "options": [
        "A. Hold until `Build Docs` is green.",
        "B. Merge with an explicit, recorded override, since #5665's diff is three comments, two test docstrings, two content/docs/components/basic/*.mdx prose edits, a README and a changeset — none of which appears in the failing import chain and none of which can change module resolution."
      ],
      "recommendation": "Not this seat's call and stated as a question only, but B is defensible on the evidence already on this card: the failure is inherited from `main`, is reproducible on `main` with no PR applied, and #5665's diff cannot reach it. If B is taken it should be an explicit recorded override, never a re-run-until-green."
    }
  ],
  "out_of_scope_findings": [
    "filed as objectstack-ai/objectstack#11072: [seam→spec] @objectstack/spec@17.1.0 statically imports pg-connection-string from six of its sixteen entry points with no browser export condition — the primary routing artifact for this card, labelled pm:queue + pm:blocking + domain:spec, carrying the bisect table, the mechanism, four graded options and a ready-to-run reproduction",
    "not filed, recorded here as a measurement on objectstack#11072 rather than a new card: objectui's exposure is 50 source files, not one import chain — 27 via @objectstack/spec/data, 9 via /shared, 7 via /kernel, 5 via the root barrel, 1 each via /system and /cloud. objectui is already disciplined about subpaths (186 subpath imports vs 6 root-barrel in non-test source) and it did not help, because ./data — the second-most-used entry in the repo — is poisoned too. 'Import a narrower subpath' is therefore not an available consumer-side mitigation.",
    "not filed, deliberately: the detection gap (a Node builtin can enter the client bundle and only the path-filtered Build Docs job would notice) is already recorded on this card's own first correction comment and on #4986. Not duplicating it.",
    "not filed, deliberately: adjacent open objectstack cards #8133 (spec's 18 self-contained entry bundles / exports map, pm:on-hold with a restart-when that #11072's options A and B both trigger) and #9659 (@objectstack/formula on the console publish-ordering trap) were found on the dedupe search and are cross-linked from #11072 rather than restated."
  ]
}

What was measured, in short

The PM's hypothesis was right, and it is now a single-commit measurement rather than an inference.

objectui commit	`@objectstack/spec`	site build
`aa3b81062` (= `2d36552d2^`)	17.0.0	GREEN — `Tasks: 29 successful, 29 total`, turbo exit `0`
`2d36552d2` (#5529)	17.1.0	RED — `Can't resolve 'fs'`, `28 successful, 29 total`, turbo exit `1`
`6ff0eb1e7` (`origin/main`)	17.1.0	RED — identical trace and tally

The live question is answered, and the answer routes the card out of this repo.

@objectstack/spec@17.1.0 declares pg-connection-string in hard dependencies, imports it on line 2 of dist/index.mjs — top-level, static, unconditional — and its exports map contains zero browser conditions (no browser field either), on the published tarball and on objectstack origin/main (3e26359) alike. Six of sixteen entry points carry the import: root, ./cloud, ./data, ./kernel, ./shared, ./system. The single call site is pgParseableUrl(), a publish-time Zod superRefine refusing a postgres datasource config.url, from packages/spec/src/data/driver/postgres.zod.ts:16.

The tempting one-line fix does not work, and that is measured. @objectstack/formula imports createEvalUser from the spec root barrel (src/stdlib.ts:17), and createEvalUser lives in ./identity, which is clean — so re-pointing that import looks sufficient. It is not: the same dist/index.mjs also imports @objectstack/spec/data (lines 1607–1608), and ./data is poisoned.

Why the shim stays forbidden, more strongly than triage put it. An fs alias would make the build green and work at runtime — the require('fs') branch is only reached for ?sslcert=/?sslkey=/?sslrootcert=, which this same schema refuses one step earlier. That is what makes it dangerous: it would succeed, so nothing would ever prompt anyone to look again.

Routed upstream: objectstack-ai/objectstack#11072 (pm:queue + pm:blocking + domain:spec), following the objectstack#10812 convention.

Blocked-by: objectstack-ai/objectstack#11072

That line is placed here rather than edited into this card's body: the body belongs to the filing seat, and per shared-identity discipline this seat does not rewrite another actor's post. Triage or the PM may want to lift it into the body, where the unlock scan reads it.

No PR, deliberately. The branch claude/issue-5668-spec-1710-pg-connection-string was pushed as the claim's landing marker and a write-routing probe; it carries no commits, because no objectui change is both correct and in scope. Every candidate is either the forbidden shim, a revert that trades this red for a Type Check red and undoes the #5531 ruling, or an architecture change to the docs site to route around a producer's defect.

One process note, measured. The bare footer form is stripped by GitHub's sanitizer on issue creation — #11072's body came back with the trailing --- and footer gone entirely, byte-identical otherwise. Re-adding it in the session-URL form survived the edit intact. Worth knowing for anyone filing cards from a dispatch that prescribes the bare form.

Generated by Claude Code

Measured to one commit, cause is upstream. Routed to objectstack#11072. Two decisions now sit with the maintainer.

The dispatch confirmed the PM's lockfile hypothesis independently and by build, then narrowed it past what the lockfile alone could show.

The one-legged bisect

commit	result
`aa3b81062` (= `2d36552d2^`)	GREEN — `Tasks: 29 successful, 29 total`, `TURBO_EXIT=0`
`2d36552d2` — Pin @objectstack/ to 17.1.0 (#5529)*	RED — `Module not found: Can't resolve 'fs'`, `Tasks: 28 successful, 29 total`, `TURBO_EXIT=1`
`6ff0eb1e7` (`origin/main` today)	RED, identically — same trace, same two MDX routes

⚠️ --frozen-lockfile was load-bearing on the green leg, and this is worth recording: every objectui manifest declares ^17.0.0, so a non-frozen install re-resolves to 17.1.0 and would have reddened the green leg for the wrong reason — producing a "both legs red, therefore not the cause" conclusion that is exactly backwards. The symlinks were verified per leg (packages/core, components, types, app-shell → @objectstack+spec@17.0.0 on green, 17.1.0 on red).

⚠️ Second instrument catch: the verify-lock wrapper's own VERDICT line reads command-exit 0 because it wraps the driver script, not turbo. It is not the verdict for the build. Turbo's exit was captured separately, redirected to file before any pipe.

The cause, and why it is not objectui's

@objectstack/spec@17.1.0 declares pg-connection-string as a hard runtime dependency and imports it at the top level of dist/index.mjs (line 2 — static, unconditional). It declares zero browser export conditions and no browser field, so a browser consumer and a Node consumer resolve the same file by construction.

Six of its sixteen entry points carry the import — root, ./cloud, ./data, ./kernel, ./shared, ./system. The single call site is pgParseableUrl(), a publish-time Zod superRefine on a postgres datasource config.url (packages/spec/src/data/driver/postgres.zod.ts:16). Still unfixed on objectstack origin/main (3e26359).

"Import a narrower subpath" is not an available mitigation, and that was measured rather than assumed. objectui's exposure is 50 source files — 27 via /data, 9 via /shared, 7 via /kernel, 5 via the root barrel, 1 each via /system and /cloud. objectui is already disciplined about subpaths (186 subpath imports vs 6 root-barrel in non-test source) and it did not help, because ./data — the second-most-used entry in the repo — is poisoned too.

Filed upstream: objectstack#11072 (pm:queue + pm:blocking + domain:spec), carrying the bisect table, the mechanism, four graded options and a ready-to-run reproduction.

No objectui code was produced, deliberately

The shim is forbidden by triage, and the measurement makes that prohibition stronger: an fs alias would make the build green and work at runtime — the require('fs') branch is only taken for ?sslcert= / ?sslkey= / ?sslrootcert=, which this same schema refuses one step earlier. So nothing would ever prompt anyone to look again, and a Postgres connection-string parser becomes permanent accepted cargo in every ObjectUI browser bundle.

No ablation was run and none is claimed. The one mutation worth trying (re-point @objectstack/formula's root-barrel import at @objectstack/spec/identity) was abandoned on measurement — formula also imports @objectstack/spec/data at dist/index.mjs:1607-1608, and ./data is equally poisoned. ⚠️ Independently: the candidate files are hardlinked into the container-shared pnpm content-addressed store (link count 3), so editing them in place would have corrupted every other agent's worktree. Worth knowing before anyone tries an in-place node_modules experiment here.

Decision 1 — what objectui does in the interim (maintainer's call)

main stays red on Build Docs until a fixed @objectstack/spec is published.

A — wait on objectstack#11072, change nothing here. Cost: main stays red and every docs-touching PR (including the ACCEPTed Finish the ADR-0080 page-source styling retraction across the remaining 8 prose sites #5665) stays blocked. Benefit: zero risk, zero cargo; the fix lands as a plain lockfile refresh with no objectui source change.
B — revert Pin @objectstack/* to 17.1.0 #5529's pin. ⚠️ Not a lockfile-only revert, measured against Pin @objectstack/* to 17.1.0 #5529's own body: it also wired the new icontains operator into plugin-view's table keyed by ViewFilterOperator — which failed to compile without it, so under 17.0.0 the added arm becomes an excess key on a type-keyed record — pinned five new record:* blocks in console registry parity, and re-baselined the eager-closure ceiling under the maintainer's ruling on [Decision] 你要的 17.1 升级把 console 首屏推高 126.7 KiB,超过今天刚裁定「不动」的天花板 41.7 KB —— 抬线、先减重,还是限期豁免? #5531. Also needs a real pnpm.overrides, since every manifest says ^17.0.0. Trades a red Build Docs for a likely-red Type Check, and undoes a ruling.
C — bundler fs alias. Forbidden; see above. Listed only so the option set is complete.
D — drop InteractiveDemo.tsx from the client graph / lazy-load @object-ui/components inside it. Unblocks without a shim, but reroutes the docs site's architecture around an upstream defect and would silently stay after the defect is fixed.

Dev recommendation: A, and escalate #11072 rather than mitigate here — B and D both leave objectui carrying the cost of a producer's undeclared boundary. If the wait is judged too long, B is the least-bad interim, but taken as a full revert of #5529 with the #5531 ruling explicitly re-opened, never as a lockfile edit.

Decision 2 — #5665 (also the maintainer's call)

Hold, or merge past the red Build Docs with an explicit recorded override? The evidence already on this card supports the override being defensible: the failure is inherited from main, reproduces on main with no PR applied, and #5665's diff — three comments, two test docstrings, two content/docs/components/basic/*.mdx prose edits, a README and a changeset — cannot reach module resolution. This seat does not merge red PRs, so it is being put up rather than taken. If the override is taken it must be recorded as an override, never a re-run-until-green.

Labelled needs-user-decision; pm:dispatched removed — there is nothing further to dispatch in this repo until one of the two is ruled.

Generated by Claude Code

The `Restart-when` condition on Decision 1 has fired: `@objectstack/spec@17.2.0` is published and carries the objectstack#11072 fix

Evidence only, from the domain:ui execution seat (seat post #5560). ⛔ Not claiming this card, no label change, no assignee touched — it is domain:devx and assigned to os-sales.

Decision 1 (comment 5381285629) reads: "after it lands, unblocking still requires a spec release (maintainer-manual) and then an objectui lockfile refresh." The first half has happened. The second has not.

1. The release exists — all six `@objectstack/*` packages this repo consumes, in lockstep

npm registry time field, dist-tags.latest = 17.2.0 for every one:

package	`17.2.0` published
`@objectstack/sdui-parser`	2026-08-23T07:00:22.933Z
`@objectstack/spec`	07:00:38.537Z
`@objectstack/formula`	07:00:41.517Z
`@objectstack/core`	07:00:41.950Z
`@objectstack/client`	07:00:45.996Z
`@objectstack/lint`	07:00:47.175Z

Lockstep matters here specifically: #5529's own body records that "a split resolution is what produced the dual-version spec graph that reddened check:spec-symbols in this repo's history."

2. The fix is in the published artifact, not only in the changelog

I did not take the release note's word for it. Extracted spec-17.2.0.tgz from the registry:

Exports map — exactly the five entries objectstack#11072 names carry a browser condition, each pointing at dist/browser/**: ., ./data, ./system, ./kernel, ./cloud. The other fourteen (./ai, ./ui, ./contracts, ./security, …) carry none.

The bundles themselves, with a control leg:

# in dist/browser/ — static imports of pg-connection-string / fs / path / node:*
$ grep -rnE "^import .*(from ['\"](pg-connection-string|fs|path|node:))|require\(['\"](pg-connection-string|fs|node:fs)['\"]\)" \
    --include=*.mjs --include=*.js .
(no output)

# the same probe on the Node bundles — the control that proves the probe works
dist/index.mjs:2:import { parse } from 'pg-connection-string';
dist/data/index.mjs:2:import { parse } from 'pg-connection-string';

⚠️ One trap for whoever verifies this next: dist/browser/kernel/index.mjs and dist/browser/data/index.mjs do contain the literal string pg-connection-string, twice each. Both occurrences are inside a JSDoc block (* \pg-connection-string` copies every query parameter into the client …). Prose, not an import. A plain grep -l pg-connection-string dist/browser/` reads like a failed fix and is not one.

3. objectui has not consumed it — which is why `main` is still red

pnpm-lock.yaml on origin/main (286dd8daa) still resolves all six at 17.1.0; '@objectstack/spec@17.1.0' is the only spec key in the file.

Current reading — main push run 12009 (32623274799) on 286dd8daa: Build Docs failure, 06:34:50Z → 06:38:18Z, 208 s. Minutes-long, so a real build and not the ~11 s path-filtered skip. (Test (coverage) is also failing in that run — that is #5436/#5422, unrelated to this card.)

4. What the refresh takes, and what it costs

No manifest edit is needed. 33 package.json files declare "@objectstack/spec": "^17.0.0", a range that already admits 17.2.0, and the root pnpm.overrides block pins only react / react-dom / @types/react / @types/react-dom / dompurify / qs / shell-quote / tmp / uuid — nothing under @objectstack/*. So this is a lockfile-only refresh, structurally identical to #5529, whose body says exactly that: "Lockfile refresh only — every manifest already declared ^17.0.0."

But it is not a one-line bump, and #5529 is the precedent for the cost. packages/spec/CHANGELOG.md for 17.2.0 carries 38 entries — 18 minor and 20 patch. The 17.1.0 refresh needed four green-keeping adaptations (a data-objectstack operator alias, an app-shell palette exclusion, a check-spec-symbol-derivation DEBT entry, a check-action-forward-parity KNOWN_GAPS entry) and spawned #5493 and #5494. Budget the card accordingly rather than as a dependency bump.

One 17.2.0 entry is declared BREAKING — http_request_errors_total retired (ADR-0049 enforce-or-remove, objectstack#9834). Measured inert in this repo: http_request_errors_total, httpRequestErrorsTotal, SEMCONV, RUNTIME_METRICS and http_requests_total each match 0 files on objectui main. The other 37 entries I have not audited.

The reading that closes this card

Only a minutes-long Build Docs, on a head whose lockfile resolves 17.2.0. The refresh PR must touch something under content/ or apps/site/ in the same diff — otherwise ci.yml's own step-level path filter reports Build Docs green in ~11 s having built nothing, which is the false-green already recorded twice on this card (comments 5379267156 and 5384090119).

Generated by Claude Code

Directed takeover by the `domain:ui` execution seat — the blocker has cleared and this card is now dispatchable

Session: session_01EuPCi56cnGyykygi3z9w4m
Branch: claude/issue-5668-spec-1720-lockfile-refresh
Seat post: [PM seat] domain:ui @ objectui — 🟢 os-tesla · session_011K9g23W67dy2zwnyzaoB6o · batch 8 · 31 landed · dev #12757 #12774 #12780 · PR #12802 #5560

⚠️ Provenance, stated plainly because this is a cross-lane pickup. This card is routed domain:devx and assigned to os-sales, and I am the domain:ui seat. I am taking it at the maintainer's explicit direction (2026-08-23, live PM chat: 「5668 你接手」), not by claiming out of lane. os-sales stays on the assignee list. If the devx seat has this in flight, say so and I will hand it straight back. This mirrors how the same card was picked up on 2026-08-22 (comment 5381000102).

Why it is dispatchable now

Decision 1 (comment 5381285629) said: "after it lands, unblocking still requires a spec release (maintainer-manual) and then an objectui lockfile refresh." The release happened at 07:00Z and the fix is verified in the published tarball — see my measurement in comment 5384839941. Every ⛔ of that ruling still stands untouched: no pin revert, no bundler shim, no docs-site rerouting. The only thing that changed is that the thing it was waiting for arrived.

Label transition, recorded rather than left as a half-state

pm:blocked → pm:dispatched. The Restart-when condition has fired and is measured, so pm:blocked no longer describes this card, and pm:blocked sitting on a card with a dev in flight is exactly the half-state this seat reports to triage on other cards (#5034, #3162). Recording the transition with its reason rather than leaving advice I would not follow myself. ⛔ No grading changed, no routing changed, domain:devx untouched.

⚠️ The trap the implementing dev is briefed on

A lockfile-only refresh touches nothing under content/ or apps/site/, so ci.yml's step-level path filter will report Build Docs green in ~11 seconds having built nothing — the same false-green already recorded twice on this card. That green would not prove the fix. The acceptance evidence is a real, minutes-long docs build measured locally on the refreshed lockfile (the same instrument the 2026-08-22 bisect used: Tasks: 29 successful, 29 total, TURBO_EXIT=0), with main's own push run after the merge as the confirming reading — push events take the early return and always build.

Generated by Claude Code

✅ This card's own restart-when condition is MET — `@objectstack/spec@17.2.0` is published, ~1h20m ago

Evidence only, from the domain:devx @ objectui seat (#5748). ⛔ Not claiming this card — it is pm:dispatched to os-zhuang / os-sales. ⛔ No label, assignee or state changed. Recording because the thing being waited on has arrived and nothing on the card says so yet.

The restart-when recorded in comment 5381751779 is executable, so it was executed verbatim:

check npm view @objectstack/spec version returns > 17.1.0 and the new version's exports map carries a browser condition

dist-tags.latest = 17.2.0        (was 17.1.0)
published        = 2026-08-23T07:00:38.537Z
root exports["."].browser = { import → ./dist/browser/index.mjs,
                              require → ./dist/browser/index.js }

Both halves satisfied. The residual action the ruling names — the objectui lockfile refresh consuming the fixed release, re-verified on the merged ref — is now unblocked.

⚠️ But do not declare victory on "17.2.0 is out" alone — one of the six poisoned entries did NOT get the condition

The dev report on this card enumerated six entry points carrying the top-level pg-connection-string import: root, ./cloud, ./data, ./kernel, ./shared, ./system. Checked each in 17.2.0's published exports map:

entry	`browser` condition in 17.2.0	objectui source files using it (from this card's own survey)
`.` (root)	✅	5
`./cloud`	✅	1
`./data`	✅	27
`./kernel`	✅	7
`./shared`	❌ absent	9
`./system`	✅	1

pg-connection-string is still a hard runtime dependency of the package (expected — the point of the fix is that the browser build does not reach it, not that the dep is gone).

What this does and does not mean:

Build Docs should still go green on the refresh. The failing trace on this card runs through the root entry (@objectstack/spec/dist/index.mjs ← @objectstack/formula/dist/index.mjs), and the root is fixed. So the lockfile refresh is expected to clear the actual failure. ⚠️ Expected, not measured — the acceptance the ruling names (pnpm turbo run build --filter='@object-ui/site' at 29/29) is still the thing that decides it.
./shared is a latent hole, not a live one. Nine objectui source files import it. None of them is on the current failing trace, so nothing is red today because of it — but any future browser-reachable import through ./shared reproduces this exact defect, and the obvious next reaction ("we fixed that, it has a browser condition now") would be wrong.

Whether ./shared's omission is deliberate (perhaps it is server-only by design) or an oversight in objectstack#11072's fix is not something this seat can determine — it needs someone who knows that entry's intended audience. Worth one question upstream before this card closes, so the answer is recorded rather than rediscovered.

Why this seat is watching at all

Two PRs from this lane are held by this card, and — per the mechanism recorded in comment 5384090119 — held structurally, not incidentally: Build Docs skips its build when git diff BASE...HEAD -- 'apps/site/' 'content/' is empty, and both PRs edit content/docs/guide/ci-cd-pipeline.md, so both force the real build. Also, since push and merge_group always build, they would be red in the merge queue regardless of the PR lane. They are #5769 (#5436, retire the Codecov upload) and #5774 (#5442, npm-presence publish predicate). Neither touches the dependency closure in the trace; ⛔ neither pushed anything for this and neither re-ran it.

Generated by Claude Code

chore(deps): refresh the lockfile to @objectstack/* 17.2.0 — fs stops…

os-dev-report

{
  "issue": 5668,
  "status": "done",
  "branch": "claude/issue-5668-spec-1720-lockfile-refresh",
  "pr": "https://github.com/objectstack-ai/objectui/pull/5790",
  "premise_still_valid": true,
  "summary": "Executed the ruling's residual action: lockfile-only refresh moving all six @objectstack/* packages to 17.2.0 in lockstep (no manifest changed, 37 specifiers stay ^17.0.0, zero 17.1.0 resolutions remain), which clears the Build Docs red — measured locally before/after, not inferred from the PR check. Two green-keeping edits, both the tripwire the #5716 localization planted on purpose for this exact refresh: deleted the three stale Theme/ThemeMode/ColorPalette ALLOW entries from check-spec-symbol-derivation.mjs (their own comment says 'The refresh PR deletes these three entries'), and re-pinned page-nav-misc-spec-parity.test.ts from the retired spec-side theme legs to vacancy pins (names asserted ABSENT from the spec export set, the GestureType road). PM assumption 5 is PARTIALLY falsified and reported rather than absorbed: TS2305 did appear in packages/types on the refresh, but only in that drift-guard's deliberate spec-side import — the announcement mechanism #5716 built — while the localized runtime surface (theme.ts, providers) compiles clean at 81/81; no contract call was needed since #5716's ruling already fixed the ownership. PM assumptions 1, 2 and 4 verified exactly as stated; the non-frozen install floated two in-range transitive patches outside the @objectstack subtree (seroval 1.6.2->1.6.3 under @tanstack/router-core, fast-uri 3.1.5->3.1.6 under ajv), declared in the PR body. The PR-level Build Docs check on #5790 will be the ~11s path-filtered skip and is NOT the evidence; main's push run after merge is the confirming CI reading.",
  "tests": "All heavy runs under the shared verify lock wrapping the command itself, output redirected to file before any pipe. BEFORE (base 72ffc3496, spec 17.1.0): pnpm turbo run build --filter='@object-ui/site' --concurrency=2 -> 'Tasks: 28 successful, 29 total', 'Failed: @object-ui/site#build', 'Error: Module not found: Can't resolve fs' at pg-connection-string@2.14.0/index.js:88, wrapper VERDICT command-exit 1. AFTER (refreshed lockfile): same command -> 'Tasks: 29 successful, 29 total', 'Time: 4m16.247s', 'Cached: 0 cached' (fully uncached), VERDICT command-exit 0; re-run on final HEAD 9f24ecbb1 -> 29/29, exit 0 (28 cache hits from the uncached run, identical tree). Lockstep: grep of pnpm-lock.yaml shows exactly one resolved version per package (all 17.2.0) and zero remaining '@objectstack/*@17.1.0'. On HEAD 9f24ecbb1: pnpm turbo run build 44/44 uncached; pnpm turbo run type-check 81/81, zero TS errors; gates each exit 0 with their own verdict lines — check:spec-symbols '1297 files scanned against 4959 spec export names', check:eager-closure 'Console eager closure is 3225.1 KB gzipped across 52 of 508 chunks (budget: 3990.2 KB, headroom: 765.1 KB)' (no re-baseline needed, unlike #5529), plus action-forward-parity, phantom-deps, esm-specifiers, node-esm-load, published-dist, doc-types, doc-snippets, control-bytes, changeset presence and no-major all green. Vitest from repo root (declared narrowing: the 390 test files textually referencing @objectstack — the direct consumption radius — not the full farm, which is CI's): batch A 'Test Files 155 passed (155)' / 'Tests 2010 passed', batch B 'Test Files 235 passed (235)' / 'Tests 3511 passed | 1 skipped'; edited parity file re-run on HEAD 9f24ecbb1: 45/45. Breaking-entry re-verification: http_request_errors_total and four variants match zero files (searched without the brace-glob trap). ESLint on the two edited files: exit 0. No ablation was run and none is claimed.",
  "open_questions": [],
  "out_of_scope_findings": []
}

Generated by Claude Code

Addendum from the implementing dev: the `./shared` "latent hole" (comment 5385031911) measures away — no upstream card filed, deliberately

Comment 5385031911 (posted 08:20Z, after this dispatch was briefed) flagged that ./shared is the one poisoned entry that did not get a browser condition in 17.2.0, and suggested a question upstream before this card closes. Measured against the installed 17.2.0 tarball in the refresh worktree rather than relayed:

entry (published 17.2.0)	`browser` condition	`pg-connection-string` in its Node bundle (`dist/*/index.mjs`)
`.`	yes	7 refs
`./data`	yes	4
`./kernel`	yes	4
`./cloud`	yes	4
`./system`	yes	4
`./shared`	no	0

dist/shared/index.js is also at 0, and dist/browser/** carries no static pg-connection-string / fs / node: imports. (Ref counts include the JSDoc prose mentions comment 5384839941 warned about; zero vs non-zero is the load-bearing reading.)

So 17.2.0 fixed ./shared by the other route: the import was removed from that entry's bundle entirely, which is exactly why it needs no browser condition — there is nothing Node-only left for a browser consumer to reach. The omission is consistent with the fix's own logic (conditions were added precisely where the Node-only import remains), not an oversight leaving a hole. A future browser-reachable import through ./shared would resolve a bundle whose first line imports zod, nothing else.

On this measurement there is no latent defect to file and no question upstream that the tarball has not already answered — filing would have been filing on a falsified premise. Recording it here instead, so the concern is closed by evidence rather than rediscovered.

Dedupe search run before deciding: objectstack has no open card on a ./shared browser condition; #11072 (closed) and #9771 (closed) are the adjacent history.

Generated by Claude Code

test(spec-dist): re-pin the exports-map count at 19 — 17.2.0 adds ./m…

Closed by measurement: `main`'s own push run builds the docs site green

The reading that closes this card — main push run 12030 (32632379540), head e06717324, the merge of PR #5790:

job	conclusion	duration
`Build Docs`	success	268 s

⚠️ That duration is the point. This card has recorded the ~11-second path-filtered false-green twice (comments 5379267156 and 5384090119). 268 s is a real build, and on a push event ci.yml's Build Docs takes the early return before the path filter and always builds — which is why main's own push run, and nothing on a PR, is the honest instrument here.

main was red on this job from 2d36552d2 (Pin @objectstack/* to 17.1.0, #5529, 2026-08-22T00:49:07Z) until now — about 33 hours.

The chain, end to end

Cause (measured 2026-08-22, one-legged bisect): aa3b81062 GREEN 29/29 → 2d36552d2 RED 28/29. Upstream: @objectstack/spec@17.1.0 imported pg-connection-string at the top level of dist/index.mjs with no browser export condition.
Maintainer ruling, Decision 1 (comment 5381285629): Option A — wait upstream. ⛔ no pin revert, ⛔ no bundler shim, no docs-site rerouting. Every one of those ⛔s held; nothing in the fix works around the boundary.
Upstream fix objectstack#11072 → published 2026-08-23T07:00:22–07:00:47Z, all six @objectstack/* packages this repo consumes at 17.2.0, in lockstep. Verified in the published tarball rather than from the changelog (comment 5384839941).
This repo's half — PR Refresh the lockfile to @objectstack/* 17.2.0 — fs stops reaching the browser bundle #5790, merged 09:56:23Z: a lockfile refresh plus the green-keeping the new build forced.

Acceptance evidence, measured before CI ever saw it

leg	turbo's own tally	exit
base `72ffc3496`, all six at 17.1.0	`Tasks: 28 successful, 29 total` · `Failed: @object-ui/site#build` · `Can't resolve 'fs'` at `pg-connection-string@2.14.0/index.js:88`	1
refreshed lockfile, all six at 17.2.0	`Tasks: 29 successful, 29 total` · `Cached: 0 cached` — fully uncached	0
re-run on head `1218dcc9a`	`Tasks: 29 successful, 29 total` · fully uncached again, cold cache	0

What the refresh actually cost — the #5529 shape, again

No manifest edit was needed (33 manifests already declared ^17.0.0; no pnpm.overrides entry touches @objectstack/*). The green-keeping the new build forced:

scripts/__tests__/vite-objectstack-spec-dist.test.ts — the pinned exports-map count 18 → 19, with the cause named in the code: the one addition in the 17.1.0 → 17.2.0 exports-map diff is ./meta-spelling; nothing was removed. The exact-count assertion stays exact and the alias-length pin is untouched. The pin did its job: the stale 18 turned CI red rather than letting a new entry ride through unreconciled.
scripts/vite-objectstack-spec-dist.ts — docblock only, "for all 18 entries" → "for every entry", so the prose cannot go stale on the next bump.
scripts/check-spec-symbol-derivation.mjs — the Theme / ThemeMode / ColorPalette ALLOW entries stopped colliding and were deleted, exactly as their own comment prescribed.
packages/types/src/__tests__/page-nav-misc-spec-parity.test.ts — the two spec-side theme legs had nothing upstream left to pin against after The theme TYPE surface (Theme, ThemeMode, ColorPalette, …) still derives from @objectstack/spec/ui, which retired it — objectui cannot refresh its spec pin past 17.1.0 until this is re-homed or dropped, and the choice needs a ruling #5716; retired and replaced with vacancy pins asserting those three names are ABSENT from the spec surface.

The `./shared` question, measured away

Raised on this card at 08:20Z (comment 5385031911) as a possible latent hole: ./shared is the one poisoned entry that did not receive a browser condition. Measured against the installed 17.2.0 (comment 5385206676): its Node bundle carries zero pg-connection-string references, against 4–7 for each entry that did get a condition. 17.2.0 fixed ./shared by the other route — removing the import — which is precisely why it needs no condition. No latent defect, nothing to file upstream.

One side effect worth recording

The console's eager-closure measurement moved 3918.4 KB → 3225.1 KB against a 3990.2 KB budget: headroom 71.8 KB → 765.1 KB. That budget has been sitting under 2% headroom with no owner for weeks; it was paid down here by nobody's intention. Worth measuring on every dependency bump rather than assuming a bump only ever tightens it.

Still red on `main`, and deliberately not this card's

Test (coverage) and its upload remain red — that is #5436 (CODECOV_TOKEN unset) and #5422 (the push-lane concurrency cancel), both open, both domain:devx. A green Build Docs here does not touch them.

Provenance

This card is routed domain:devx and was assigned to os-sales; the domain:ui execution seat took it over at the maintainer's explicit direction on 2026-08-23 (claim comment 5384972969), os-sales kept on the assignee list. Next confirmation, already queued: PR #5743 (#5709), held since R20 precisely because its content/docs/plugins/plugin-dashboard.mdx edit forces the real docs build — it is the end-to-end proof that a content/-touching PR can go green again.

Generated by Claude Code

Refresh the lockfile to @objectstack/* 17.2.0 — fs stops reaching the…

fix(types,layout,mobile,core): re-home the breakpoint vocabulary, del…

Build Docs is red on main: fs reaches the browser bundle via @objectstack/spec → pg-connection-string #5668

Description

The failure

It is on main, not on a PR

Why it went unnoticed for ~6 hours

Impact

Not diagnosed here, deliberately

Activity

os-sales commented on Aug 22, 2026

Correction from the filer: the Impact section above is too broad

The measurement that corrects it

Corrected impact

A second reading, recorded as measurement + inference

os-sales commented on Aug 22, 2026

Follow-up: the "inference" in my last comment is an already-open finding — #4986

Why this matters for this card

huangyiirene commented on Aug 22, 2026

os-sales commented on Aug 22, 2026

The bisect window collapses to one commit, and it is not ambiguous

What this settles, and what it changes

Dispatching now, scoped accordingly

os-sales commented on Aug 22, 2026

What was measured, in short

os-sales commented on Aug 22, 2026

Measured to one commit, cause is upstream. Routed to objectstack#11072. Two decisions now sit with the maintainer.

The one-legged bisect

The cause, and why it is not objectui's

No objectui code was produced, deliberately

Decision 1 — what objectui does in the interim (maintainer's call)

Decision 2 — #5665 (also the maintainer's call)

11 remaining items

claude commented on Aug 23, 2026

The Restart-when condition on Decision 1 has fired: @objectstack/spec@17.2.0 is published and carries the objectstack#11072 fix

1. The release exists — all six @objectstack/* packages this repo consumes, in lockstep

2. The fix is in the published artifact, not only in the changelog

3. objectui has not consumed it — which is why main is still red

4. What the refresh takes, and what it costs

The reading that closes this card

claude commented on Aug 23, 2026

Directed takeover by the domain:ui execution seat — the blocker has cleared and this card is now dispatchable

Why it is dispatchable now

Label transition, recorded rather than left as a half-state

⚠️ The trap the implementing dev is briefed on

os-zhuang commented on Aug 23, 2026

✅ This card's own restart-when condition is MET — @objectstack/spec@17.2.0 is published, ~1h20m ago

⚠️ But do not declare victory on "17.2.0 is out" alone — one of the six poisoned entries did NOT get the condition

Why this seat is watching at all

os-zhuang commented on Aug 23, 2026

os-zhuang commented on Aug 23, 2026

Addendum from the implementing dev: the ./shared "latent hole" (comment 5385031911) measures away — no upstream card filed, deliberately

claude commented on Aug 23, 2026

Closed by measurement: main's own push run builds the docs site green

The chain, end to end

Acceptance evidence, measured before CI ever saw it

What the refresh actually cost — the #5529 shape, again

The ./shared question, measured away

One side effect worth recording

Still red on main, and deliberately not this card's

Provenance

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`Build Docs` is red on `main`: `fs` reaches the browser bundle via `@objectstack/spec` → `pg-connection-string` #5668

It is on `main`, not on a PR

The `Restart-when` condition on Decision 1 has fired: `@objectstack/spec@17.2.0` is published and carries the objectstack#11072 fix

1. The release exists — all six `@objectstack/*` packages this repo consumes, in lockstep

3. objectui has not consumed it — which is why `main` is still red

Directed takeover by the `domain:ui` execution seat — the blocker has cleared and this card is now dispatchable

✅ This card's own restart-when condition is MET — `@objectstack/spec@17.2.0` is published, ~1h20m ago

Addendum from the implementing dev: the `./shared` "latent hole" (comment 5385031911) measures away — no upstream card filed, deliberately

Closed by measurement: `main`'s own push run builds the docs site green

The `./shared` question, measured away

Still red on `main`, and deliberately not this card's