Observational finding, filed unassigned by the os-dev seat working #14093 (branch claude/issue-14093-action-method-example-path, PR #15098). Not fixed there — out of that card's declared file surface, which is the method docblock in action.zod.ts only.
What
packages/spec/src/ui/action-row-update.test.ts:155-159 — the positive control in the row-level declarative-write suite — spells the same erroneous data-API path the method docblock was just corrected for:
it('positive control — the api and script forms are untouched by the new refinements', () => {
expect(ActionSchema.safeParse({
name: 'revoke', label: 'Revoke', type: 'api', target: '/api/v1/sys_api_key/{id}',
method: 'PATCH', bodyExtra: { revoked: true }, recordIdParam: 'id',
}).success).toBe(true);The shipped data door is PATCH /api/v1/data/:object/:id (packages/rest/src/rest-server.ts:7664 composing getApiBasePath() with crud.dataPrefix, registered at :7913-7914; the /data default is packages/spec/src/api/rest-server.zod.ts:252). The fixture's path is missing the /data segment, and its id placeholder is a bare {id} where target's documented convention is ${ctx.X} / ${param.X} (action.zod.ts:992-997).
Why it is a finding and not a bug
Nothing is broken and no gate reds. target is z.string(), so the path value carries no assertion weight — this test asserts only that the type: 'api' form still parses, and it does. The fixture also does not publish: @objectstack/spec ships dist/** and src/**/*.zod.ts, and a .test.ts matches neither.
What it costs is consistency. This fixture appears to have been copied from the docblock it sits next to; with PR #15098 correcting that docblock, this line becomes the last place in the repo spelling the wrong shape. An author or agent grepping sys_api_key for a worked example of that route now finds one corrected site and one stale one, with nothing marking which is which — the same "reason confidently from the wrong text" input the parent card is about, one layer down and without the 404.
Suggested
Either update the fixture to /api/v1/data/sys_api_key/${ctx.recordId} to match the corrected docblock, or — since the path is inert to this assertion — replace it with an obviously-illustrative value so it cannot be mistaken for a worked example at all. Deliberately not decided here.
Triage note: severity judged at filing time is unreliable in both directions, so this is filed plainly rather than graded. No assignee.
Generated by Claude Code
Generated by Claude Code
Observational finding, filed unassigned by the
os-devseat working #14093 (branchclaude/issue-14093-action-method-example-path, PR #15098). Not fixed there — out of that card's declared file surface, which is themethoddocblock inaction.zod.tsonly.What
packages/spec/src/ui/action-row-update.test.ts:155-159— the positive control in the row-level declarative-write suite — spells the same erroneous data-API path themethoddocblock was just corrected for:The shipped data door is
PATCH /api/v1/data/:object/:id(packages/rest/src/rest-server.ts:7664composinggetApiBasePath()withcrud.dataPrefix, registered at:7913-7914; the/datadefault ispackages/spec/src/api/rest-server.zod.ts:252). The fixture's path is missing the/datasegment, and its id placeholder is a bare{id}wheretarget's documented convention is${ctx.X}/${param.X}(action.zod.ts:992-997).Why it is a finding and not a bug
Nothing is broken and no gate reds.
targetisz.string(), so the path value carries no assertion weight — this test asserts only that thetype: 'api'form still parses, and it does. The fixture also does not publish:@objectstack/specshipsdist/**andsrc/**/*.zod.ts, and a.test.tsmatches neither.What it costs is consistency. This fixture appears to have been copied from the docblock it sits next to; with PR #15098 correcting that docblock, this line becomes the last place in the repo spelling the wrong shape. An author or agent grepping
sys_api_keyfor a worked example of that route now finds one corrected site and one stale one, with nothing marking which is which — the same "reason confidently from the wrong text" input the parent card is about, one layer down and without the 404.Suggested
Either update the fixture to
/api/v1/data/sys_api_key/${ctx.recordId}to match the corrected docblock, or — since the path is inert to this assertion — replace it with an obviously-illustrative value so it cannot be mistaken for a worked example at all. Deliberately not decided here.Triage note: severity judged at filing time is unreliable in both directions, so this is filed plainly rather than graded. No assignee.
Generated by Claude Code
Generated by Claude Code