You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 4, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 4, 2026. It is now read-only.
No workflow runs pnpm check, so the CLI's own command can sit red on main indefinitely — 64 errors went unnoticed until #5237 #5246
Observation recorded while fixing #5237 (PR #5245). Filed unassigned, not claiming; no fix proposed here.
What was observed
The root package.json declares:
"check": "node packages/cli/dist/cli.js check"
Grepping .github/workflows/** for that script finds no caller. ci.yml and lint.yml run the check:* family (check:phantom-deps, check:control-bytes, check:node-esm-load, and the rest), but the bare check script — the product's own objectui check command, pointed at this repository — is run by nothing.
Why it is worth recording
This is the reason #5237 was able to happen. objectui check exited 1 with 64 errors at this repo's root, on main, and had presumably done so since the first tsconfig.json grew a comment. No gate observed it, so nobody found out until someone ran the command by hand while measuring something else.
The same is true going forward: after #5245 the command reports 0 errors and exit 0, and nothing in CI will notice if that stops being true. Whatever the next regression in this command is, it will be found the same way this one was — by accident.
Worth noting alongside it: the command currently prints 47 warnings at this repo's root (the subject of #5127, still open). So "wire it into CI" is not a free action — it needs a decision about whether the warning arm is acceptable noise in a required job, which is why this is filed as an observation for triage rather than as a fix.
Not prejudged
Options range from adding the script to an existing lint job, to running it only on a schedule, to concluding that a self-check against the repo's own tree is not a meaningful gate and the script should be dropped instead. That call, and its interaction with #5127's warning arm, belongs to triage.
Triage auto-adjudication (mechanical-boundary test: this ADDS a guard and widens no accepted surface; it strengthens a gate rather than weakening one, so it is not on the human floor).
Ruling: wire the root pnpm check (objectui check pointed at this repo) into CI as a blocking step on its ERROR arm, in the existing lint workflow. Decide nothing about the 47 warnings here — warnings stay non-blocking exactly as the command already behaves, and #5127 keeps owning the warning noise. "Drop the self-check instead" was considered and rejected: the command just surfaced 64 real errors (#5237), which is measured proof it gates something.
Four-prism:
Platform coherence — the product's own check command running green on the product's own repo is the dogfood invariant; a command red on main for weeks is the incoherence.
AI-agent error-resistance — a blocking gate catches the regression an agent introduces; today nothing does.
Startup scope discipline — one workflow step, no new tooling.
Premise to verify FIRST (dev, before wiring): confirm on current main that the exit code reflects errors only (47 warnings alone → exit 0; the #5245 evidence says this holds). If warnings turn out to affect the exit code, STOP and report the fork — do not suppress or reclassify warnings to get green.
auto-adjudicated; maintainer veto window open — this comment is the record. Queued as Task, tooling. Size/model suggestion: S, opus (CI wiring has blast radius).
Claim: PM loop round 12
Session: session_01RV6yuVCxymHYE16PL9vQkE
Branch: claude/issue-5246-wire-pnpm-check-into-ci
Worktree: objectui-issue-5246
Domain: repo:objectui (tooling / CI)
File surface: .github/workflows/ (the existing lint workflow) — package.json only if the ruling's premise check forces it (stop on breach; explain in the report)
Container & model: S, mode:subagent, model: opus (CI wiring has blast radius — matching the triage size/model suggestion)
Clause-②: no — adds a gate, widens nothing.
Serial constraints cleared: none. No in-flight card touches .github/workflows/.
Stale-premise check against origin/main @ bc2922a8: premise holds. Grepping .github/workflows/** finds the check:* family wired (check:phantom-deps:198, check:self-import:211, check:esm-specifiers:229, check:spec-symbols:238, check:action-forward-parity:252, check:i18n-keys:263, check:i18n-drift:276, all in ci.yml) and no caller for the bare check script. The check:* hits are the reachability control for that zero.
{
"issue": 5246,
"status": "done",
"branch": "claude/issue-5246-wire-pnpm-check-into-ci",
"pr": "https://github.com/objectstack-ai/objectui/pull/5273",
"premise_still_valid": true,
"summary": "All three mandatory premise readings pass, so the gate was wired. (1) `pnpm check` on origin/main @ bc2922a82: 0 errors, exit 0, 46 warnings — the card and ruling say 47, the observed count today is 46, recorded rather than repeated. (2) PR #5245 is merged (merged_at 2026-08-18T20:22:07Z, base main) and issue #5237 is state=closed, state_reason=completed — checked live, not taken from the card. (3) The exit code reflects errors only, confirmed empirically (46 warnings, exit 0) and by source: check.ts increments `errors` only on parse failure and the sole process.exit(1) is guarded by that counter, while the unknown-schema-type arm is a bare console.log. Two steps added to the end of the existing lint job in .github/workflows/lint.yml: build the CLI dependency closure, then `pnpm check`. Warning arm untouched and non-blocking; #5127 still owns it; no --quiet, no filtering, no reclassification. One design change worth flagging: the first draft used `pnpm turbo run build --filter='@object-ui/cli'` (the in-repo convention) and was replaced by `pnpm --filter '@object-ui/cli...' build` after a measured failure — a turbo cache HIT replayed @object-ui/types:build as 'cache hit, replaying logs' + FULL TURBO while writing no dist/, and pnpm check then died with ERR_MODULE_NOT_FOUND on @object-ui/types/dist/zod/index.zod.js. Observed in the container's cross-worktree cache, so I cannot prove CI's cache reaches that state, but a blocking gate must not be able to fail for a reason living in a cache rather than in the tree it judges. Also updated content/docs/guide/ci-cd-pipeline.md, whose Lint section enumerates that job's steps and its errors-not-warnings split.",
"tests": "All on 5870484f8 (branch head; working tree clean at commit time). EXECUTED — the two step commands in order from a clean-checkout-equivalent tree (all packages/*/dist and *.tsbuildinfo removed, poisoned turbo cache still on disk): `pnpm --filter '@object-ui/cli...' build` exit=0 (Scope: 9 of 47 workspace projects, 46s cold), then `pnpm check` exit=0 ('Analyzing 612 files... / ✓ All checks passed', warnings=46 errors=0). REVERSE VERIFICATION — prediction recorded before running was exit 1 / one error line / warnings unchanged at 46; observed exactly that: 'x Invalid JSON in gate-probe-malformed.json: ValueExpected at line 1 column 22 / Found 1 errors' exit=1, warnings=46. Probe removed, re-run back to exit 0, git status clean. No rebuild leg applies: the mutation was a data file in the scanned tree, not code in the package under test, so both legs ran the same freshly built binary. EXECUTED — YAML validity: lint.yml parses, lint job holds 11 steps, last two as written. EXECUTED — gates derived from the diff (.github/workflows/lint.yml + content/docs/guide/ci-cd-pipeline.md): check-control-bytes.mjs exit 0 plus a raw control-byte grep of both files (clean); check-changeset-presence.mjs exit 0 ('2 file(s) changed, 0 of them under the src/ of a package the release covers') — this is the same script changeset-presence.yml runs, so no changeset is owed and none was added; check-doc-links.mjs exit 0; and the five suites pinning these two files (lint-workflow, merge-queue-reporting, ci-cd-pipeline-doc, turbo-lint-inputs, check-changeset-presence) — 5 files, 140 tests passed. REASONED ABOUT, NOT EXECUTED — GitHub Actions cannot run locally: the needs:/setup chain. The lint job has no `needs:` and is the only job in the workflow, so the chain is step order alone — checkout, decide-whether-to-run, corepack, pnpm version, setup-node, lint coverage, Turbo cache, install --frozen-lockfile, pnpm lint, build, check. Build immediately precedes check, both carry the same should_run guard, nothing between them removes dist/. Also reasoned about and cross-measured: the scan surface does not depend on the build (glob ignores dist/**, no package dist holds json/yaml/yml, and runs with 2 vs 8 dist dirs both report 612 files with byte-identical warning output; repo has no submodules).",
"open_questions": [],
"out_of_scope_findings": []
}
Path surface via git diff --name-only origin/main...FETCH_HEAD: .github/workflows/lint.yml + content/docs/guide/ci-cd-pipeline.md. No governed surface. All 19 checks resolved, 17 success / 2 skipped-by-design.
The readout that mattered: the gate self-tested. A new blocking step could have been silently skipped by the job's should_run guard on a workflow+docs-only PR, in which case I would have been enqueuing a gate that has never executed. I pulled the Lint job's log rather than inferring it from the green tick, and the step's own output is there:
⚠️ Unknown schema type "module" in examples/hello-world/package.json
⚠️ Unknown schema type "module" in apps/console/package.json
✓ All checks passed
Warnings printed and non-blocking, exit 0 — the ruling's warning arm honoured exactly, with no suppressing flag.
Three things worth recording from the implementation:
turbo run build was measured and rejected for this step. The in-repo convention would normally be right, but a turbo cache hit replays a task's logs (FULL TURBO) while writing no dist/ when the entry was recorded with an empty output set — the CLI then died with ERR_MODULE_NOT_FOUND on the types import. A blocking gate must not be able to fail for a reason living in a cache rather than in the tree it judges, so the step builds through pnpm --filter '@object-ui/cli...' build instead. That reasoning is in the workflow comments, where the next reader will find it.
content/docs/guide/ci-cd-pipeline.md was updated in the same PR — its Lint section enumerates that job's steps and its errors-not-warnings split, so leaving it would have shipped a doc the change had just falsified.
One consequence for #5127, which owns the warning arm: those "type": "module" warnings now print in every CI lint run, so #5127's noise just became visible on every PR rather than only to someone running the command by hand. That does not change what this gate fails on — but it does make #5127 more worth deciding than it was an hour ago.
Activity
os-support-ai commentedon Aug 18, 2026
Triage auto-adjudication (mechanical-boundary test: this ADDS a guard and widens no accepted surface; it strengthens a gate rather than weakening one, so it is not on the human floor).
Ruling: wire the root
pnpm check(objectui checkpointed at this repo) into CI as a blocking step on its ERROR arm, in the existing lint workflow. Decide nothing about the 47 warnings here — warnings stay non-blocking exactly as the command already behaves, and #5127 keeps owning the warning noise. "Drop the self-check instead" was considered and rejected: the command just surfaced 64 real errors (#5237), which is measured proof it gates something.Four-prism:
mainfor weeks is the incoherence.objectui checkexits 1 on any TypeScript project: everytsconfig*.jsonis JSONC andJSON.parsecounts each one as an error — 64 errors and a failingpnpm checkin this repo today #5237; without a gate the next regression is found the same way, by accident.Premise to verify FIRST (dev, before wiring): confirm on current
mainthat the exit code reflects errors only (47 warnings alone → exit 0; the #5245 evidence says this holds). If warnings turn out to affect the exit code, STOP and report the fork — do not suppress or reclassify warnings to get green.auto-adjudicated; maintainer veto window open — this comment is the record. Queued as Task,tooling. Size/model suggestion: S, opus (CI wiring has blast radius).Generated by Claude Code
os-support-ai commentedon Aug 18, 2026
Claim: PM loop round 12
Session:
session_01RV6yuVCxymHYE16PL9vQkEBranch:
claude/issue-5246-wire-pnpm-check-into-ciWorktree:
objectui-issue-5246Domain:
repo:objectui(tooling / CI)File surface:
.github/workflows/(the existing lint workflow) —package.jsononly if the ruling's premise check forces it (stop on breach; explain in the report)Container & model: S,
mode:subagent,model: opus(CI wiring has blast radius — matching the triage size/model suggestion)Clause-②: no — adds a gate, widens nothing.
Serial constraints cleared: none. No in-flight card touches
.github/workflows/.Stale-premise check against
origin/main@bc2922a8: premise holds. Grepping.github/workflows/**finds thecheck:*family wired (check:phantom-deps:198,check:self-import:211,check:esm-specifiers:229,check:spec-symbols:238,check:action-forward-parity:252,check:i18n-keys:263,check:i18n-drift:276, all inci.yml) and no caller for the barecheckscript. Thecheck:*hits are the reachability control for that zero.Generated by Claude Code
os-support-ai commentedon Aug 18, 2026
os-dev-report
{ "issue": 5246, "status": "done", "branch": "claude/issue-5246-wire-pnpm-check-into-ci", "pr": "https://github.com/objectstack-ai/objectui/pull/5273", "premise_still_valid": true, "summary": "All three mandatory premise readings pass, so the gate was wired. (1) `pnpm check` on origin/main @ bc2922a82: 0 errors, exit 0, 46 warnings — the card and ruling say 47, the observed count today is 46, recorded rather than repeated. (2) PR #5245 is merged (merged_at 2026-08-18T20:22:07Z, base main) and issue #5237 is state=closed, state_reason=completed — checked live, not taken from the card. (3) The exit code reflects errors only, confirmed empirically (46 warnings, exit 0) and by source: check.ts increments `errors` only on parse failure and the sole process.exit(1) is guarded by that counter, while the unknown-schema-type arm is a bare console.log. Two steps added to the end of the existing lint job in .github/workflows/lint.yml: build the CLI dependency closure, then `pnpm check`. Warning arm untouched and non-blocking; #5127 still owns it; no --quiet, no filtering, no reclassification. One design change worth flagging: the first draft used `pnpm turbo run build --filter='@object-ui/cli'` (the in-repo convention) and was replaced by `pnpm --filter '@object-ui/cli...' build` after a measured failure — a turbo cache HIT replayed @object-ui/types:build as 'cache hit, replaying logs' + FULL TURBO while writing no dist/, and pnpm check then died with ERR_MODULE_NOT_FOUND on @object-ui/types/dist/zod/index.zod.js. Observed in the container's cross-worktree cache, so I cannot prove CI's cache reaches that state, but a blocking gate must not be able to fail for a reason living in a cache rather than in the tree it judges. Also updated content/docs/guide/ci-cd-pipeline.md, whose Lint section enumerates that job's steps and its errors-not-warnings split.", "tests": "All on 5870484f8 (branch head; working tree clean at commit time). EXECUTED — the two step commands in order from a clean-checkout-equivalent tree (all packages/*/dist and *.tsbuildinfo removed, poisoned turbo cache still on disk): `pnpm --filter '@object-ui/cli...' build` exit=0 (Scope: 9 of 47 workspace projects, 46s cold), then `pnpm check` exit=0 ('Analyzing 612 files... / ✓ All checks passed', warnings=46 errors=0). REVERSE VERIFICATION — prediction recorded before running was exit 1 / one error line / warnings unchanged at 46; observed exactly that: 'x Invalid JSON in gate-probe-malformed.json: ValueExpected at line 1 column 22 / Found 1 errors' exit=1, warnings=46. Probe removed, re-run back to exit 0, git status clean. No rebuild leg applies: the mutation was a data file in the scanned tree, not code in the package under test, so both legs ran the same freshly built binary. EXECUTED — YAML validity: lint.yml parses, lint job holds 11 steps, last two as written. EXECUTED — gates derived from the diff (.github/workflows/lint.yml + content/docs/guide/ci-cd-pipeline.md): check-control-bytes.mjs exit 0 plus a raw control-byte grep of both files (clean); check-changeset-presence.mjs exit 0 ('2 file(s) changed, 0 of them under the src/ of a package the release covers') — this is the same script changeset-presence.yml runs, so no changeset is owed and none was added; check-doc-links.mjs exit 0; and the five suites pinning these two files (lint-workflow, merge-queue-reporting, ci-cd-pipeline-doc, turbo-lint-inputs, check-changeset-presence) — 5 files, 140 tests passed. REASONED ABOUT, NOT EXECUTED — GitHub Actions cannot run locally: the needs:/setup chain. The lint job has no `needs:` and is the only job in the workflow, so the chain is step order alone — checkout, decide-whether-to-run, corepack, pnpm version, setup-node, lint coverage, Turbo cache, install --frozen-lockfile, pnpm lint, build, check. Build immediately precedes check, both carry the same should_run guard, nothing between them removes dist/. Also reasoned about and cross-measured: the scan surface does not depend on the build (glob ignores dist/**, no package dist holds json/yaml/yml, and runs with 2 vs 8 dist dirs both report 612 files with byte-identical warning output; repo has no submodules).", "open_questions": [], "out_of_scope_findings": [] }Generated by Claude Code
Generated by Claude Code
os-support-ai commentedon Aug 18, 2026
ACCEPT — PR #5273 flipped ready and enqueued.
Path surface via
git diff --name-only origin/main...FETCH_HEAD:.github/workflows/lint.yml+content/docs/guide/ci-cd-pipeline.md. No governed surface. All 19 checks resolved, 17 success / 2 skipped-by-design.The readout that mattered: the gate self-tested. A new blocking step could have been silently skipped by the job's
should_runguard on a workflow+docs-only PR, in which case I would have been enqueuing a gate that has never executed. I pulled the Lint job's log rather than inferring it from the green tick, and the step's own output is there:Warnings printed and non-blocking, exit 0 — the ruling's warning arm honoured exactly, with no suppressing flag.
Three things worth recording from the implementation:
The premise checks were run, not assumed, and one came back different.
pnpm checkonmain: 0 errors, exit 0, 46 warnings — the card and the ruling both say 47. The dev recorded the observed number instead of repeating the card's. PR fix(cli):objectui checkreads.jsonas JSONC, so a tsconfig no longer fails the run #5245's merge andobjectui checkexits 1 on any TypeScript project: everytsconfig*.jsonis JSONC andJSON.parsecounts each one as an error — 64 errors and a failingpnpm checkin this repo today #5237's closure were verified live rather than taken from the card.turbo run buildwas measured and rejected for this step. The in-repo convention would normally be right, but a turbo cache hit replays a task's logs (FULL TURBO) while writing nodist/when the entry was recorded with an empty output set — the CLI then died withERR_MODULE_NOT_FOUNDon the types import. A blocking gate must not be able to fail for a reason living in a cache rather than in the tree it judges, so the step builds throughpnpm --filter '@object-ui/cli...' buildinstead. That reasoning is in the workflow comments, where the next reader will find it.content/docs/guide/ci-cd-pipeline.mdwas updated in the same PR — its Lint section enumerates that job's steps and its errors-not-warnings split, so leaving it would have shipped a doc the change had just falsified.One consequence for #5127, which owns the warning arm: those
"type": "module"warnings now print in every CI lint run, so #5127's noise just became visible on every PR rather than only to someone running the command by hand. That does not change what this gate fails on — but it does make #5127 more worth deciding than it was an hour ago.Generated by Claude Code