[objectstack-fleet]

Closes #24654

Clause-②: no

What changed

Four customer-facing sentences said "in 17.x", but 18.x is the running major and the behaviour they describe has not changed. Each one now says what the runtime does without naming a version, so it cannot go stale again at 19.0. ⛔ No behaviour change, no new gate.

where	reader	now reads
packages/spec/src/api/endpoint-publish-gate.ts	the os build / os validate refusal for a script / proxy endpoint	"This runtime executes only 'object_operation' and 'flow' endpoints. script is refused because ..."
packages/runtime/src/endpoint-executor.ts (hint)	the API caller, in the unsupported answer	"This runtime executes only 'object_operation' and 'flow' endpoints. 'script' and 'proxy' are rejected at publish ..." (word for word the same first sentence as the spec refusal)
packages/spec/src/api/endpoint.zod.ts type describe	readers of the published schema	"Implementation type — this runtime EXECUTES only 'object_operation' and 'flow'. ..."
packages/spec/src/api/endpoint.zod.ts ApiMapping.transform describe	the same	"Transformation function name — NOT EXECUTED by this runtime, and publish REJECTS the key ..."

Same PR, maintainer-facing JSDoc: packages/runtime/src/api-mapping.ts (the mirrored transform describe row) and packages/runtime/src/endpoint-executor.ts (the params "always {}" notes and the planEndpointTarget doc).

Bounded in-place fix, named here: packages/spec/src/api/endpoint.zod.ts, ApiEndpoint.target describe, said the Script Name / Proxy URL spellings "stay unreachable in 17.x". It is the same defect class, in the same file, on the same schema, and the same gate family covers it (check:docs). It now reads "stay unreachable on this runtime". Evidence: the regenerated content/docs/references/api/endpoint.mdx row for target.

Pins: no test asserted the old text (git grep -nE "execute in 17|EXECUTED in 17|EXECUTE in 17" over *.test.ts returns 0 hits). Two test TITLES in packages/runtime/src/endpoint-executor.test.ts repeated "in 17.x". They were reworded and their assertions are unchanged.

Regenerated with repo tooling: pnpm --filter @objectstack/spec check:generated --fix found check:docs stale (1 of 14), regenerated content/docs/references/api/endpoint.mdx and re-checked it green. Changeset: .changeset/24654-endpoint-text-version-free.md, patch for @objectstack/spec and @objectstack/runtime.

Verification (head f8e3a95abf, which includes a merge of origin/main 0431002104)

• pnpm --filter @objectstack/spec build && pnpm --filter @objectstack/spec check:generated, post-merge: "All 14 generated artifacts are up to date", lock VERDICT command-exit 0.
• pnpm --filter @objectstack/spec test at f8e3a95abf: 701 files passed, 1 skipped; 21347 tests passed. pnpm --filter @objectstack/spec typecheck: exit 0.
• pnpm --filter @objectstack/runtime test && pnpm --filter @objectstack/runtime typecheck at 018b472bd5 (the change itself, before the merge): 425 files passed; 6678 tests passed, 19 skipped; typecheck exit 0. The merge brought no change to the files this PR edits. The runtime suite was not re-run on the merge head; CI runs it there.
• node scripts/pm/dispatch-gates.mjs --commands derived 110 commands at f8e3a95abf. All of them were run, and --ran reconciles: "110 derived famil(ies) accounted for — 109 run, 1 NOT-MEASURED".
  • NOT MEASURED: check:dual-build-cjs-loads. Reason: PREREQUISITE NOT MET (exit 3). It needs a full workspace build, and this worktree only built the runtime dependency closure.
  • check:lean-entry-closure first exited 1 because @objectstack/spec dist was missing: a spec rebuild was running at the same time. Re-run after the build finished: exit 0.

Acceptance notes

Other "in 17.x" sites outside this card's file surface. None of them was edited here:

• packages/rest/src/openapi-endpoints.ts:218: unsupportedReason says "which this runtime does not execute in 17.x". This is customer-facing OpenAPI output for the same endpoint family. It is reported to the seat as a finding.
• skills/objectstack-api/SKILL.md:163: "script / proxy do not execute in 17.x". This is the published skill text, a Tier H surface. It is reported to the seat.
• packages/spec/src/stack.zod.ts:845 (JSDoc), packages/spec/src/contracts/metadata-service.ts:210 (JSDoc, with the test title metadata-service.test.ts:485), packages/spec/src/automation/flow-node-expression-paths.ts:126 (JSDoc), packages/spec/liveness/api.json:15 (ledger note): maintainer-facing only.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/runtime, @objectstack/spec, touching 6 documentable anchor(s). ⚠️ 1 changed file(s) yielded no anchor (packages/runtime/src/api-mapping.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/declarative-endpoints.mdx (via ApiEndpointSchema (symbol, a top-level const object), object_operation (literal, a string literal in ApiEndpointSchema; a string literal in planEndpointTarget; a string literal in targetGate))
• content/docs/getting-started/quick-reference.mdx (via object_operation (literal, a string literal in ApiEndpointSchema; a string literal in planEndpointTarget; a string literal in targetGate))
• content/docs/protocol/kernel/http-protocol.mdx (via ApiEndpointSchema (symbol, a top-level const object), object_operation (literal, a string literal in ApiEndpointSchema; a string literal in planEndpointTarget; a string literal in targetGate))

What this run could not see

• 1 changed file(s) yielded no anchor (packages/runtime/src/api-mapping.ts) — pages documenting those are invisible to this run
• the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 148 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 9e2722a923d29d3367ab38d2dee6023b696af8ea → packageMentionDocs.

Which tree this was computed on

This run read content/docs from c007cd839dce15a7d754cc47f07c7b00d9767a20 — the merge of head f8e3a95abf11534a5e051db5193fbb6afb905cf3 into base 9e2722a923d29d3367ab38d2dee6023b696af8ea, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin c007cd839dce15a7d754cc47f07c7b00d9767a20 && git checkout c007cd839dce15a7d754cc47f07c7b00d9767a20
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 9e2722a923d29d3367ab38d2dee6023b696af8ea f8e3a95abf11534a5e051db5193fbb6afb905cf3 && git checkout -B drift-repro 9e2722a923d29d3367ab38d2dee6023b696af8ea && git merge --no-ff f8e3a95abf11534a5e051db5193fbb6afb905cf3

node scripts/docs-audit/affected-docs.mjs --json 9e2722a923d29d3367ab38d2dee6023b696af8ea

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 9e2722a923d29d3367ab38d2dee6023b696af8ea → pass the list as
args.docs, on the commit named under Which tree this was computed on.