`tool.objectName` is `live` on a basis the cloud walk falsified — the re-grade needs an objectui reader, which #13042's container did not have

[os-project-manager]

Spun out of the #13042 re-closure (PR #13275). That card re-closed five of the six tool.json entries against cloud origin/main@15f55df; this is the sixth, deliberately left live and UNDATED rather than stamped or re-graded. Recording the measurement so the next reader starts from it instead of re-deriving it.

What was measured, at framework ba76fb7d / cloud 15f55df

packages/spec/liveness/tool.json rests every verdict on the basis its own _note states: tool metadata is write-only, and a prop is live because the runtime consumes the same-named field on AIToolDefinition, not because anything reads tool metadata back.

Applied to objectName, that basis does not hold:

1. Both cited sites read a different key. packages/service-ai/src/tools/action-tools.ts, at actionToToolDefinition and createActionToolHandler, reads action.objectName — the ActionSchema key. action.json's own objectName row carries the identical citation, packages/services/service-ai/src/tools/action-tools.ts:535, word for word. The tool ledger appears to have inherited the action ledger's pointer.
2. The same-named field is written and never read. AIToolDefinition.objectName is set at actionToToolDefinition and read by nothing: zero readers across the cloud repo (git grep over all non-test packages/**/*.ts, checked against every getAll() / getDefinition() consumer — ai-service.ts, eval-runner.ts, agent-routes.ts, assistant-routes.ts, tool-routes.ts), and zero in this repo. The near-misses are all tool arguments, not the definition: security-enterprise/.../tool-interceptor.ts extractObjectName, service-ai-studio/.../open-record.tool.ts.
3. It never reaches persisted metadata either. Cloud has exactly one metadataService.register site for tool (in service-ai-studio/src/plugin.ts), and it ingests only the shipped Studio definition lists — none of them action-backed, none carrying objectName.

This is the producer-with-no-consumer shape the ledger README records for seed.env, arriving from the other end.

Why it was not re-graded to dead in #13042

The one candidate reader left is an objectui read-back of a persisted tool record. No objectui checkout was reachable in that container, so the negative could not be closed. The README is explicit that a negative cross-repo claim resting on a search that cannot see the renderer is the app.homePageId / #4895 failure shape — a verdict that was wrong precisely because the renderer was outside the search.

Leaving the entry undated keeps it on the --stale-verification worklist, which is where a claim that could not be closed belongs. Its note carries the full measurement.

The work

Walk objectui for any read of a persisted tool record's objectName — the metadata-admin preview read points for the tool type first, per the #7131 mechanical rule (registerMetadataPreview('tool'), recording an absent preview as a finding rather than skipping it. Then either:

• a reader exists ⇒ stamp verifiedAt, repoint the evidence at it with an objectui @sha realm marker, and note that the verdict rests on the read-back rather than on the AIToolDefinition surface — which would also mean this file's _note overstates the write-only framing; or
• no reader exists ⇒ re-grade live to dead under ADR-0049. Note that this moves the tool row in packages/spec/liveness/state-counts.md (currently 13 | 1 | 0 | 0 | 14), so the regen is part of that change, and #13042's single-file fence is why it was not done there.

Executor constraint: a container with an objectui checkout. A framework-only or framework-plus-cloud container can only repeat the measurement above; it cannot close it.

Related: #13272 (the same stale-path defect in agent.json / skill.json / action.json).

[os-project-manager]

Answered — the objectui walk was taken, and the reader exists. Recording the full reading before closing.

Provenance

A read-only objectui checkout became reachable mid-session at a non-standard path (/home/user/objectstack-ai/objectui); the dispatching PM seat pointed at it and supplied two candidate lines, which I verified myself rather than adopting. All readings below are git -C … show/grep origin/main, never a working tree. Zero writes to objectui, no worktree there.

Measured at objectui origin/main@26896c6 (tip on 2026-08-29). The PM's reading was taken at d06059f; that commit is an ancestor of the tip, and ToolPreview.tsx is byte-identical at both (blob df3d5132e28d228396699beb82d7a632c2822415), so the reading is stable across the two shas.

The reader

packages/app-shell/src/views/metadata-admin/previews/ToolPreview.tsx, in ToolPreview:

const objectName = (d.objectName as string | undefined) || undefined;
...
{objectName && (
 <div className="mt-1 flex flex-wrap items-center gap-x-3 gap-y-1 text-[11px]">
 <Pill icon={Database} label={objectName} mono />
 </div>
)}

d is the persisted tool record's body. Registered as the tool type's preview (previews/index.ts, registerMetadataPreview('tool', ToolPreview)), and the registration is resolved and handed a draft by ResourceEditPage.tsx via getMetadataPreview(type) — so the read point is reachable, not merely present, which is the half the #7131 rule insists on citing.

It is also deliberately pinned. ToolPreview.test.tsx asserts the pill renders and that the row disappears when the key is removed, over a comment reading:

objectName is NOT residue — ToolSchema still accepts it.

I searched objectui for any other, behavioural consumer and found none: the only other file holding both a tool token and objectName is clientValidation.ts, whose objectName is derived from d.name and has nothing to do with this key.

Verdict: live as a DISPLAY key — and the reasoning inverts, not the verdict

Both halves are now on the record, and each is load-bearing:

1. The old basis stays falsified. The row claimed "action-tool dispatch". Both cited cloud sites read action.objectName (the ActionSchema key, whose action.json row carries that citation verbatim), and the same-named AIToolDefinition.objectName is written by actionToToolDefinition and read by nothing in cloud or framework. The key gates, binds and routes nothing.
2. A real consumer exists on the other basis — the metadata read-back. Under finding: "no runtime consumer" on docs-shaped dead ledger rows is contradicted by metadata-admin previews — JobPreview renders job.label/job.description, TranslationPreview renders translation.label/.name #7131 that settles a display key, and for authored tool metadata the render is not standing in for a behaviour, because ToolSchema's own describe says a metadata-authored tool is a read-only projection no executor loads. There is no second layer for the preview to proxy.

So live stands, as display and never as a binding, and the entry now says exactly that. Explicitly not an ADR-0049 retirement candidate: a dead verdict would have retired a key the renderer deliberately renders and tests — the requiresService / colorVariant lesson from the other end. The previous pass's refusal to grade dead while objectui was unreachable was the right call; the renderer was where the answer lived.

Wider correction this forced

tool.json's _note claimed for years that tool metadata is "WRITE-ONLY … not metadata read-back". That is false, and it is precisely why nobody looked at the renderer. ToolPreview reads all six props off the stored record — name, label, description, objectName, parameters, outputSchema. The type has two live bases (the AIToolDefinition surface, behavioural; and the metadata read-back, display), and every row now names the one it rests on.

Landed on PR #13275 at 4bc1737c (branch claude/issue-13042-tool-liveness-reclose, still draft). Liveness family green on that commit: verifiedAt 452 to 453 (all six entries now dated, 0 undated in this file), cross-repo scope 69 to 70, producers 15 to 16, and state-counts.md is current — no verdict moved, so the counts are untouched.

Closing as answered.

---

Generated by Claude Code