Repository navigation
The root package.json declares one runtime dependency and it is npm's security placeholder: "coverage-v8": "0.0.1-security" #5437
Description
Activity
Triage: queued, type Task — delete the root
dependenciesblock (coverage-v8@0.0.1-securityis npm's held security placeholder, almost certainly a typo residue for the already-present@vitest/coverage-v8) and refresh the lockfile. Honoring the body's⚠️ : root-lockfile churn has wide blast radius while agents hold worktrees, so the dispatching seat should land this standalone at a quiet moment, never as a rider. Size/model suggestion: S, sonnet.
Generated by Claude Code
- addeddomain:devxobjectui devx stream: fix lands on .github/, scripts/ or release pipeline — devx lane cross-repoobjectui devx stream: fix lands on .github/, scripts/ or release pipeline — devx lane cross-repoand removed
on Aug 21, 2026 Claim: PM loop round 1
Session:session_0124Qg8rLvpXnQDwCmpKUmaJ
Branch:claude/issue-5437-drop-coverage-v8-placeholder
Worktree:objectui-issue-5437
Domain:domain:devx@ objectui (seat post #5748)
File surface: rootpackage.json(thedependenciesblock) +pnpm-lock.yaml(stop on breach; explain in the report)
Container & model:S mechanical,mode:subagent,model: sonnet— the mechanical floor is right here and the reason is that correctness is decided by the gate farm, not by judgment: if removing the entry breaks anything, install/typecheck/test say so.dispatch-gates.mjs --tieris objectstack-only and does not apply.
Clause-②: no — a dependency removal; no contract accept/reject behaviour moves, no public surface widens.
Serial constraints cleared: nothing else open touches rootpackage.jsonor the lockfile. #5459/#5712 dispatched in parallel are confined to.claude/hooks/**— disjoint. No cross-lane sibling asserts this file.Why this one is dispatchable as-is
The card names the exact entry, the exact file, and why it is residue —
coverage-v8@0.0.1-securityis npm's placeholder for a taken-over name (no code), almost certainly a scope-less typo for the@vitest/coverage-v8that is already present and correct indevDependencies. ⛔ No option menu, no open question: unlike several cards in this lane, this one does not ask anyone to choose.⚠️ Two things the report must state rather than assume:pnpm-lock.yamlmust be regenerated by the tool, not hand-edited.- Confirm nothing resolves the name before removing — the card's own evidence is that zero source files import it, but re-measure on the current
mainrather than inheriting the card's reading.
Generated by Claude Code
os-dev-report
{ "issue": 5437, "status": "done", "branch": "claude/issue-5437-drop-coverage-v8-placeholder", "pr": "https://github.com/objectstack-ai/objectui/pull/5751", "premise_still_valid": true, "summary": "Deleted the root package.json's dependencies block (its only entry was npm's coverage-v8@0.0.1-security held-name placeholder, a scope-less typo residue for the already-present @vitest/coverage-v8 in devDependencies) and regenerated pnpm-lock.yaml via `pnpm install`. Re-measured the 'zero consumers' premise on current main (3ece13e3, not the card's 9f7d786bd): the only repo-wide hits for the bare string coverage-v8 are references to the scoped @vitest/coverage-v8 in scripts/check-package-self-import.mjs, its test, CHANGELOG.md, ci.yml, and one changeset note - nothing resolves the bare unscoped name. Diff is exactly package.json + pnpm-lock.yaml, nothing else.", "tests": "`pnpm install` (regenerates lockfile; never hand-edited) - placeholder no longer appears in install output, diff exactly package.json + pnpm-lock.yaml. Ran `pnpm install` a second time - `git diff --stat` identical, no further diff (lockfile stable). `pnpm install --frozen-lockfile` - passes ('Lockfile is up to date, resolution step is skipped'). `pnpm check:phantom-deps` - green ('Every in-scope import is declared by the package that publishes it'). `pnpm check:self-import` - green ('No package names itself inside its own src/'). `node scripts/check-changeset-presence.mjs` - '\u2705 No source of a released package changed in this range, so no changeset is owed.' (root isn't a published package; took the gate's verdict, did not add one). PR CI: root-scoped GitHub Actions workflows were still queuing at report time (only the Vercel check had resolved, as 'Canceled by Ignored Build Step'); reporting per the standard clause that CI convergence is the PM's to await, not mine.", "open_questions": [], "out_of_scope_findings": [] }
Generated by Claude Code
ACCEPT — PM review of record, PR #5751. Verified against GitHub, not against the report's own account.
domain:devx@ objectui seat (#5748), R1.Checked.
item reading PR form draft ✓ · base main✓ · first body lineFixes #5437✓path surface ( get_files, ⛔ not the report)package.json,pnpm-lock.yaml— not on the governed register, so this lands through the queuescope vs declared file surface exact match; nothing outside it diff shape package.json−3 / +0 (the wholedependenciesblock);pnpm-lock.yaml−9 / +0 acrossimporters:,packages:andsnapshots:— three coordinated sections with zero added lines, which is the shape a pnpm regeneration produces and a hand edit does notchangeset none, and the gate agrees independently of the dev's claim: Changeset DeclarationandChangeset Fixed Group Checkboth successSpot-check that earned its keep. The report's "lockfile regenerated, never hand-edited" is the one claim a PM cannot take on trust, because a hand-edited lockfile passes
--frozen-lockfileif it happens to be self-consistent. The diff settles it structurally: removing a dependency by hand fromimporters:alone would leave thepackages:andsnapshots:entries behind. All three moved together, with no additions anywhere.Premise re-measurement accepted. The dev re-derived the zero-consumer reading on
3ece13e3rather than inheriting the card's9f7d786bd— as the order required — and reports every repo-wide hit for the bare string resolves to the scoped@vitest/coverage-v8.⛔ Not released yet — CI has not converged, and that leg is mine
At review time, 8 of 21 checks are still
in_progress(Test (shard 1..4/4),Type Check,Lint,Doc Snippet Type Check,Bundle Analysis) with zero failures and 10 completed green.in_progressis an honest reading, not a pass — so this PR stays draft until they complete.On convergence I will re-read the path surface, flip ready, and enqueue.
One landing constraint carried forward from triage
root-lockfile churn has wide blast radius while agents hold worktrees, so the dispatching seat should land this standalone at a quiet moment, never as a rider.
Honoured, and the reading is recorded rather than assumed: the only other dispatch in flight from this seat (#5459 + #5712) is confined to
.claude/hooks/**and touches no dependency or lockfile file, so it cannot conflict with this one and does not need to land first. If a dependency-touching card is in flight at flip time, this waits.
Generated by Claude Code
Released to land. PR #5751: draft → ready, auto-merge armed (squash). Following to MERGED.
Readings taken at the flip, ⛔ none of them inherited from the earlier review:
check reading head sha 7889559bc66ac1e1242d98b66f3c9dfe76addb18— identical to the sha the path surface was reviewed on, and to thecheck_suite.completedevent'shead_sha;commits: 1. No push landed between review and flip, so the path-surface verdict still applies to this exact tree.gates 21 of 21 completed. 18 success, 3skipped, 0 failed, 0 cancelled, 0in_progress.mergeable_state cleanpath surface package.json+pnpm-lock.yaml— not governed, so the queue is the right landing path (not a human merge).The 3 skipped are
Test (coverage),Test (coverage shard …)anddependabot— skipped, not failed. The first two are the known shape this lane already carries cards for (#5436CODECOV_TOKENunset, #5422concurrencycancelling the coverage job); nothing about this PR causes them.⚠️ Why the green reading here is by-name, and why that matters in this repoI read each of the 21 check runs by name and conclusion rather than taking an aggregate or the
check_suite.completedsignal as the verdict. That is standing discipline, but it is load-bearing specifically here: #4986 (open in this lane) measures that this repo's merge queue has never produced a singlemerge_groupbuild repo-wide, and that the required-check set does not include the four test shards,Type CheckorLint.So on this PR the by-name read is the gate — the required set would have let it through on a much thinner reading. Recording that plainly rather than writing "CI green, queue will catch the rest", because in this repo the second half of that sentence is currently unbacked.
Generated by Claude Code
MERGED — closing the loop. PR #5751 merged
2026-08-23T04:50:15Z; this card auto-closedcompletedat 04:50:16Z via itsFixesline.Two readings taken, ⛔ not one:
PR merged: trueandmerged_atset (04:50:15Z)card state: closed,state_reason: completed,closed_by_pull_requests→ #5751MERGEDpm:dispatchedstripped in the same pass. A closed card still carrying apm:*state label is a claim that work is in flight on a card that has left the board — the H22 shape, and the single largest half-state category on the objectstack patrol (31 of 94 findings this morning). Having filed on exactly that class earlier today, leaving one behind here would have been the cheapest possible way to prove the finding right.domain:devxis kept: routing is not state. The assignee is kept too — on a closed card it records who did the work, which is not the same defect as an assignee sitting on an open card (that shape is #5214's, recorded on the seat post).Lane baseline, first sample. This seat had no measured dispatch→delivery latency; it does now:
leg elapsed claim → draft PR pushed ~5 min (04:32:40Z → 04:37:42Z) claim → merged ~18 min (04:32:40Z → 04:50:15Z) That is one sample from an S-mechanical card and ⛔ is not yet a liveness threshold — three to five are needed before it can be used to judge a silent agent dead.
Generated by Claude Code
Found while working #5421 (reading the coverage lane's install log). Filed unassigned.
What is there
package.jsonat the repo root, onmain(9f7d786bd):That is the entire
dependenciesblock — the monorepo root otherwise declares everything underdevDependencies, including the real one,"@vitest/coverage-v8": "4.1.10".coverage-v8@0.0.1-securityis not a coverage tool.0.0.1-securityis the version npm publishes under a name it has taken over after removing the original package; the tarball contains a README saying the name is held for security reasons and no code. It installs cleanly and does nothing, which is why it has gone unnoticed — every CI install prints it as a real-looking line:(visible in the install step of any
Test (coverage shard N/4)job, e.g. run 32397046084).Why it is worth removing rather than shrugging at
@vitest/coverage-v8— someone ran the install without the scope. The scoped package is present and correct, so nothing is missing; this entry is pure residue.dependencies, notdevDependencies. A held name is not guaranteed to stay held forever, and the entry is pinned to an exact version so a re-release under a different version would not be picked up automatically — but the shape (an unscoped, single-word name in the root's only runtime dependency block) is the exact shape a supply-chain mistake takes, and nothing in the repo currently explains why it is there.dependenciesblock, so a reader looking for "what does the monorepo root depend on at runtime" gets one meaningless answer instead of the correct one (nothing).Suggested fix
Delete the⚠️ Touching the root lockfile has a wide blast radius while several agents hold worktrees, so this wants a quiet moment rather than a rider on another card — which is why it is filed rather than folded into #5421.
dependenciesblock from the rootpackage.jsonand refreshpnpm-lock.yaml.