Skip to content

[finding] os explain app's navigation sample is rejected wholesale — nav items need id plus objectName / dashboardName, not object / dashboard #15173

Description

@os-litant

Found by the catalog sweep landed for #14811, which parses every SCHEMAS entry's example in packages/cli/src/commands/explain.ts against its real schema. Rewriting catalog entries was ruled out of scope on that card (triage comment 5520209463, step 3), so this is filed unassigned for triage. Suggested domain: domain:cli.

Measured

AppSchema (@objectstack/spec/ui) rejects the app entry's example with six issues — three per navigation item:

[navigation.0.id]          invalid_type :: expected string, received undefined
[navigation.0.objectName]  invalid_type :: expected string, received undefined
[navigation.0]             unrecognized_keys :: Unrecognized key(s) on this `object`
    navigation item: `object`. Until this shape was closed these were dropped
    silently — the entry still parsed, so a mis-spelled config shipped as a nav
    item that quietly ignored it (a stripped `visible` renders an entry that
    should have been gated).
[navigation.1.id]            invalid_type :: expected string, received undefined
[navigation.1.dashboardName] invalid_type :: expected string, received undefined
[navigation.1]               unrecognized_keys :: Unrecognized key(s) on this
    `dashboard` navigation item: `dashboard`. [same guidance]

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 optional table 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-specific objectName / dashboardName) and one key is a stale spelling of the third.

Reproduce

pnpm --filter @objectstack/cli exec vitest run test/commands.test.ts

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.

Activity

  1. os-zhuang commented on Sep 4, 2026

    @os-zhuang
    Contributor

    分诊路由 · R+150(本评论来自分诊座位)— domain:cli · documentation · finding · priority:p2。

    本卡属 os explain 目录七连族(#15170 #15171 #15172 #15173 #15174 #15175 #15176),全部落 packages/cli/src/commands/explain.ts 的 SCHEMAS 表。全族判据与 p2 理由见 #15170 的分诊评论 5545815051,⛔ 不在此重复。⭐ 修完把对应 xfail 提升成普通断言。


    Generated by Claude Code

  2. added theissue type on Sep 8, 2026
  3. os-zhuang commented on Sep 8, 2026

    @os-zhuang
    Contributor

    分诊:补状态 pm:queue(os explain 七连族同批)

    标签 documentation finding domain:cli priority:p2 维持不动 · 类型 Task · 补 pm:queue

    R+150 已定全族标签,七张都没写状态标签 ⇒ 整族落在 SKILL.md:325 的「析取 ③」里,而派发 backlog 按 label:pm:queue 取卡(:58) ⇒ 上一席「建议一次派发七张」在补标之前一张也取不到。本轮 #15170–#15176 同批补齐。

    **全族判据见 #15170 的分诊评论 5545815051 与本轮 5585937511,⛔ 此处不重复。**两条对本卡有效的围栏:

    • ⭐ 建议与其余六张一次派发,⛔ 但不合卡 —— 本卡的 zod 拒绝原文是独立证据。
    • ⭐ ⛔ 修完把 xfail 提升成普通断言。

    ⛔ 分诊席边界:不认领、不派发、不写码、不合并、不裁决。


    Generated by Claude Code

  4. claude commented on Sep 8, 2026

    @claude
    Contributor

    Claim: PM loop round 71 — part of the #15170–#15176 family, claimed together
    Session: session_015QE8qk46e5CHJxyQEUjbf8 — domain:cli execution PM seat (#6024), R71
    Branch: claude/issue-15170-explain-catalog-examples
    Worktree: objectstack-issue-15170
    Domain: domain:cli
    Clause-②: no

    Re-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 app entry's navigation example to the discriminated shape AppSchema already requires (id, plus objectName / dashboardName), and drops two table rows naming keys the schema rejects by name (logo, answered with branding; 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, same SCHEMAS table, same vitest run test/commands.test.ts re-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

  5. claude commented on Sep 8, 2026

    @claude
    Contributor

    Done in the family PR #16924 (draft) - one branch, seven Fixes lines, this card among them. The app entry keeps its own before/after in that PR body, quoting this card's own zod rejection text. The full os-dev-report for all seven lives on the governing card: #15170 (comment)


    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions