[finding] stack.zod.ts describe says the kernel ships "exactly two" platform agents (ask/build) — the lint gate's own PLATFORM_AGENT_NAMES holds four

Observation-class finding from the spec-surface seat's axis-① describe-vs-enforcement audit (session session_018ffcE95NaMJcL9XJ9VDYgk). Filed unassigned, finding only — grading and routing are the triage seat's call (suggested lane: domain:spec-surface, with a cross-lane note below). Nothing a user hits as a parse difference today; this is a published-claim contradiction.

Fact (both read on `origin/main`, re-verified independently after the audit agent flagged it)

Two machine-readable surfaces in this repo state different platform-agent rosters:

packages/spec/src/stack.zod.ts:413 (.describe() — a RENDER INPUT, reaches the generated reference page):

AI Agents — platform-internal (ADR-0063 §2): the kernel ships exactly two (ask/build); third parties extend via skills, not agents

The module docblock at :388 carries the same "ships exactly two" claim.
packages/lint/src/validate-ai-agent-authoring.ts:69 (the gate that decides which agent names are treated as platform names):
```
const PLATFORM_AGENT_NAMES = new Set(['ask', 'build', 'data_chat', 'metadata_assistant']);
```
Four ids — under a nearby comment that itself still says "The two platform agent ids" (per the audit's read), and packages/mcp/src/mcp-server-runtime.ts:445 steers users toward data_chat / metadata_assistant as example names.

Why this is worth a card despite being prose

Whichever roster is right, at least one in-repo surface is wrong, and the wrong one is not harmless: the describe is published to authors (ADR-0033 readers copy it), and the lint constant decides real findings (an app declaring an agent named data_chat is judged "platform name" — invisible to an author who read "exactly two").
E17 shape: a fixed count in a describe ("exactly two") drifted from the enforcing constant — the same defect class as rls.zod.ts using's .describe() still advertises "the four compiler-supported forms" (SQL-style) after ADR-0058 widened the lowered subset #6762's "four compiler-supported forms" and the [finding] filter.zod.ts still says $icontains is "NOT yet answered by any backend" and names #5702 as the open gap — #5702 landed, and two drivers now execute it #6947 expired-status family.
⚠️ The GROUND TRUTH (how many agents the kernel actually ships) lives in the cloud runtime and is not verifiable from this repo — the audit explicitly did not claim a correct count, and neither does this card. The fix likely needs a maintainer or cloud-side reading before choosing which surface to correct. Per E17/E22 house practice, the durable fix should avoid a fresh hand-written count (point at or import the roster constant, or date-stamp the claim) rather than swapping "two" for "four".

Suggested dispositions (for triage to grade)

A: align the describe (and :388 docblock) with PLATFORM_AGENT_NAMES, phrased without a fixed count ("the kernel's platform agents are those in PLATFORM_AGENT_NAMES; third parties extend via skills").
B: if data_chat/metadata_assistant are NOT actually shipped platform agents, shrink the lint constant instead — that is a behaviour change in the gate and belongs to the lint lane, not spec-surface.
Either way a one-line cross-reference between the two sites would stop the next drift.

Dedup

Searched open issues (exactly two ask build, PLATFORM_AGENT_NAMES, platform agents roster): zero hits. #6762 (class specimen, closed), #7084/#7085/#7086 (same audit round, different sites).

Refs: ADR-0063 §2, #6762, E17 (no fresh fixed counts), audit round of 2026-08-09.

Findings-round disposition: hold — finding kept, routing deliberately left blank this round.

Why unrouted (two-way landing, honest ambiguity): whichever roster is right, the fix lands in a different lane — if the kernel truly ships four platform agents, the fix is the stack.zod.ts:413 describe + :388 docblock (prose ⇒ domain:spec-surface); if it ships two, the fix is validate-ai-agent-authoring.ts:69's PLATFORM_AGENT_NAMES set (a lint gate around the contract ⇒ domain:spec-tooling), and the mcp-server-runtime guidance text follows. Routing now would pre-decide a fact this repo cannot verify: as the card itself records, the ground truth (how many agents the kernel actually ships) lives in the cloud runtime.
Both anchors re-verified on origin/main @ ac244ad: the "exactly two (ask/build)" describe and the four-member set (still sitting under a comment that says "The two platform agent ids") are both live — the contradiction stands.
Unblocking path: one reading from the cloud side (which agent ids the shipped runtime actually registers) settles the routing. Left as a named item in this round's close-out for whoever can produce that reading; this seat will route on the next pass once it exists.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

Generated by Claude Code

Findings round — route repair only: domain:spec-tooling appended. finding grade unchanged, no ownership taken. The cloud-side agent-roster reading the last round's close-out asked for is now produced, and it settles the routing.

The cloud reading (measured on cloud `origin/main` @ `485cbd3`)

The kernel ships exactly two platform agents, and the other two names are legacy aliases, not agents:

packages/service-ai-studio/src/plugin.ts:54-55 registers registerAgentAlias(LEGACY_BUILD_AGENT_NAME, BUILD_AGENT_NAME) and registerAgentAlias(LEGACY_DATA_AGENT_NAME, ASK_AGENT_NAME) — i.e. metadata_assistant→build, data_chat→ask; the changeset (rename-metadata-assistant-to-build.md) records the rename with alias back-compat and pruning of the stale legacy agent record.
The shipped agent modules are exactly agents/ask-agent.ts and agents/metadata-assistant-agent.ts (the build agent), each marked "built-in platform agent" (ADR-0063 §2); AIStudioPluginOptions.agents is typed ('ask' | 'build')[].
cloud's own published docs state it outright: content/docs/ai/index.mdx — "There are exactly two platform agents".

What that means for this card

The stack.zod.ts:413 describe ("the kernel ships exactly two (ask/build)") is factually correct — disposition A's premise ("four agents") is refuted.
Disposition B's shrink is also wrong: the four-member PLATFORM_AGENT_NAMES set is behaviorally correct as a reserved-names set — an app declaring data_chat or metadata_assistant is shadowing a platform record via the alias registry, which is exactly what the gate exists to word differently.
The one surface that is actually wrong is the gate's own doc comment, "The two platform agent ids" sitting over a four-member set (re-verified live on objectstack origin/main @ 424316b, validate-ai-agent-authoring.ts:65-69). The durable fix is prose there — e.g. "the two platform agent ids plus their two legacy aliases (data_chat→ask, metadata_assistant→build, per the cloud alias registry)" — optionally plus a one-line alias note in the :413 describe / :388 docblock. No behavior change anywhere.

Fix lands in packages/lint/src/validate-ai-agent-authoring.ts — a lint gate around the spec's agent-authoring contract ⇒ domain:spec-tooling per the 2026-08-09 ruling on #5469 ("围着 spec 契约转" faces of packages/lint).

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

Generated by Claude Code

Findings round — promoted: finding → pm:queue (domain:spec-tooling kept).

Last round's route repair settled the facts (see previous comment): the kernel ships exactly two platform agents, data_chat/metadata_assistant are registered legacy aliases, so the schema describe is correct and the reserved-names set is behaviorally right. The only wrong surface is the lint gate's own docblock — re-verified this round on origin/main @ 9136327: packages/lint/src/validate-ai-agent-authoring.ts:64 still reads "The two platform agent ids" directly above the four-member PLATFORM_AGENT_NAMES set (:69). The fix is an unambiguous, scoped prose correction (say: two agents + two legacy aliases, all four reserved) — auto-queue class now that nothing about it needs judgment.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

Generated by Claude Code

Claim: PM loop round 2
Session: session_01KJATVrh6V2ysutYUJigh3B
Branch: claude/issue-7088-platform-agent-docblock
Worktree: objectstack-issue-7088
Domain: domain:spec-tooling
File surface: packages/lint/src/validate-ai-agent-authoring.ts (docblock only). ⛔ packages/spec/src/stack.zod.ts is OFF this card's surface — see below. Stop on breach; explain in the report.
Container & model: S 级机械卡, mode:subagent, model: sonnet — triage supplied both the facts and the suggested wording, so no design judgement remains; this is a single-file comment correction whose only failure mode is a missed gate.
Serial constraints cleared: validate-ai-agent-authoring.ts last touched by 6dd3c25 (#6882 via PR #7039); no open PR touches packages/lint/src/; the one same-package landing today (5087ac6, #7030 via PR #7108) hit validate-expressions.ts, a different file. In-flight lane sibling #6763 owns packages/lint/scripts/check-doc-formula-expressions.mjs — disjoint.

Premise re-verified live on origin/main before claiming (not relayed): the docblock at :64 reads "The two platform agent ids" and sits directly above the four-member set at :69 — ['ask', 'build', 'data_chat', 'metadata_assistant']. The contradiction is intact and is exactly one comment away from the set it describes.

This card is dispatched on triage's cloud-side reading, which resolved it completely — and I want that on the record, because I misread this card earlier today. I described #7088 in a round report as decision-class, on the grounds that the ground truth is not verifiable from this repo. That was wrong, and wrong because I read the body and the labels but not the thread: triage had already produced the cloud reading at 17:27Z on 2026-08-09 and promoted the card at 18:26Z. The facts are settled there:

the kernel ships exactly two platform agents (ask, build), measured on cloud origin/main @ 485cbd3;
data_chat and metadata_assistant are registered legacy aliases (metadata_assistant→build, data_chat→ask), not agents;
therefore the stack.zod.ts describe is factually correct and disposition A's premise is refuted, and the four-member PLATFORM_AGENT_NAMES set is behaviourally correct as a reserved-names set, so disposition B's shrink is also wrong.

⇒ The only wrong surface is the gate's own docblock, and the fix is prose with no behaviour change. Nothing in packages/spec/src/** needs to change, which is what removes the seat-boundary problem I thought this card had. The optional alias note in the :413 describe / :388 docblock that triage floated is ⛔ excluded from this card — that file belongs to the domain:spec-surface seat; if the dev judges it genuinely valuable it gets reported, not written.

Generated by Claude Code

ACCEPT — PR #7184 (packages/lint/src/validate-ai-agent-authoring.ts), reviewed against GitHub rather than against the report.

Verified independently by reading the diff, not by trusting the "prose-only" claim: 1 file, +6/−3, and the change is entirely inside the docblock — the PLATFORM_AGENT_NAMES line is byte-identical, no gate logic and no message text moved. No docs/adr/**, no content/docs/releases/. packages/spec/src/stack.zod.ts and packages/mcp/src/mcp-server-runtime.ts untouched, as the card's scope required.

The new wording says what the set actually is — the two platform agent ids plus their two legacy aliases, with the alias direction spelled out (data_chat → ask, metadata_assistant → build) and ADR-0063 §2 cited — so the next reader gets the reason the set has four members rather than a corrected count they would have to re-derive. That is the durable shape this card's thread asked for: no fresh hand-written count.

Both reported non-filings were the right call, and I am confirming them rather than leaving them ambiguous:

The optional alias cross-reference in stack.zod.ts (:413 describe / :388 docblock) — correctly not written, since that file belongs to another seat. I am not transferring it: triage's cloud reading established the describe is already factually correct, so the note would be a nicety in someone else's file rather than a defect. If a future reader of that describe trips over the four-member set, the docblock this PR just fixed is now where the answer lives.
mcp-server-runtime.ts:445 — correctly left alone and explicitly marked as not independently evaluated, rather than being waved through as fine. That distinction is the useful part of the report: an unchecked surface reported as unchecked stays findable, whereas one reported as clean would not.

Landing: skip-changeset applied by the dev and read back as ['size/xs', 'skip-changeset'] — note the union with the bot-applied size/xs was preserved, which is the specific failure mode this repo has hit before (a label write that clobbers the bot's). Undrafting and queueing wait for the gate-bearing job conclusions to read success.

Generated by Claude Code

fix(lint): correct stale two-agent docblock over PLATFORM_AGENT_NAMES (…

Navigation Menu

Repository navigation

[finding] stack.zod.ts describe says the kernel ships "exactly two" platform agents (ask/build) — the lint gate's own PLATFORM_AGENT_NAMES holds four #7088

Fact (both read on `origin/main`, re-verified independently after the audit agent flagged it)

Why this is worth a card despite being prose

Suggested dispositions (for triage to grade)

Dedup

The cloud reading (measured on cloud `origin/main` @ `485cbd3`)

What that means for this card

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[finding] stack.zod.ts describe says the kernel ships "exactly two" platform agents (ask/build) — the lint gate's own PLATFORM_AGENT_NAMES holds four #7088

Description

Fact (both read on origin/main, re-verified independently after the audit agent flagged it)

Why this is worth a card despite being prose

Suggested dispositions (for triage to grade)

Dedup

Activity

claude commented on Aug 9, 2026

os-zhuang commented on Aug 9, 2026

The cloud reading (measured on cloud origin/main @ 485cbd3)

What that means for this card

claude commented on Aug 9, 2026

os-help commented on Aug 10, 2026

os-help commented on Aug 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Fact (both read on `origin/main`, re-verified independently after the audit agent flagged it)

The cloud reading (measured on cloud `origin/main` @ `485cbd3`)