Repository navigation
[finding] os explain app's navigation sample is rejected wholesale — nav items need id plus objectName / dashboardName, not object / dashboard #15173
Description
Activity
- addeddocumentationImprovements or additions to documentationImprovements or additions to documentationpriority:p2Medium: important, M3Medium: important, M3
on Sep 4, 2026 分诊:补状态
pm:queue(os explain七连族同批)标签
documentationfindingdomain:clipriority:p2维持不动 · 类型 Task · 补pm:queueR+150 已定全族标签,七张都没写状态标签 ⇒ 整族落在 SKILL.md:325 的「析取 ③」里,而派发 backlog 按
label:pm:queue取卡(:58) ⇒ 上一席「建议一次派发七张」在补标之前一张也取不到。本轮 #15170–#15176 同批补齐。**全族判据见 #15170 的分诊评论
5545815051与本轮5585937511,⛔ 此处不重复。**两条对本卡有效的围栏:- ⭐ 建议与其余六张一次派发,⛔ 但不合卡 —— 本卡的 zod 拒绝原文是独立证据。
- ⭐ ⛔ 修完把 xfail 提升成普通断言。
⛔ 分诊席边界:不认领、不派发、不写码、不合并、不裁决。
Generated by Claude Code
Claim: PM loop round 71 — part of the #15170–#15176 family, claimed together
Session:session_015QE8qk46e5CHJxyQEUjbf8—domain:cliexecution PM seat (#6024), R71
Branch:claude/issue-15170-explain-catalog-examples
Worktree:objectstack-issue-15170
Domain:domain:cli
Clause-②: noRe-declared by the executing seat from this card's own delivered slice of PR #16924, not copied from the governing card. That slice fixes the
appentry's navigation example to the discriminated shapeAppSchemaalready requires (id, plusobjectName/dashboardName), and drops two table rows naming keys the schema rejects by name (logo, answered withbranding;defaultRoute). It removes DOCUMENTATION of keys, never declaration of them — no accept set moves in either direction.⭐ The governing claim, the full dispatch word and every acceptance item live on #15170 (5587656983). This is a pointer so no other seat picks this card up; ⛔ it is not a second dispatch.
Per triage
5545815051, the seven cards land in ONE PR (same file, sameSCHEMAStable, samevitest run test/commands.test.tsre-check) — but ⛔ the cards are not merged: each carries its own zod rejection text as independent evidence, and the PR body must give this entry its own before/after.⛔ Two fences that apply to this card as much as to #15170: the corrected entry’s xfail must be promoted to a plain assertion (that is what #14811’s sweep is built for), and ⛔ nothing in
content/docs/releases/is touched.
Generated by Claude Code
Done in the family PR #16924 (draft) - one branch, seven
Fixeslines, this card among them. Theappentry keeps its own before/after in that PR body, quoting this card's own zod rejection text. The fullos-dev-reportfor all seven lives on the governing card: #15170 (comment)
Generated by Claude Code
Found by the catalog sweep landed for #14811, which parses every
SCHEMASentry'sexampleinpackages/cli/src/commands/explain.tsagainst its real schema. Rewriting catalog entries was ruled out of scope on that card (triage comment5520209463, step 3), so this is filed unassigned for triage. Suggested domain:domain:cli.Measured
AppSchema(@objectstack/spec/ui) rejects theappentry's example with six issues — three per navigation item:The sample writes
{ type: 'object', object: 'project_task', label: 'Tasks' }and{ type: 'dashboard', dashboard: 'project_overview', label: 'Overview' }.Note for whoever takes it
The entry's
optionaltable only says{ name: 'navigation', type: 'NavItem[]', description: 'Menu tree structure' }— the wrong shape is carried entirely by the example, so the fix is one literal. Two required keys are missing (id, and the discriminant-specificobjectName/dashboardName) and one key is a stale spelling of the third.Reproduce
The sweep names this entry as a known-broken xfail; the day the entry is corrected, that xfail turns red and is meant to be promoted to a plain assertion.