T-DIMU-lint-entity-base-yaml-templates

Status: planning/backlog · Impact: medium · Complexity: small

Auto-generated from a /sdlc:task-work post-mortem. Review and promote to open/ready before picking up.

Reframed 2026-06-03. The Obsidian-Bases view template was renamed base.yaml → obsidian-index.yaml (the base.yaml name now belongs solely to scaffolder frontmatter defaults), resolving the filename collision this task worked around. check_entity_bases.ts already parse-validates each obsidian-index.yaml; the residual work here is the column↔schema assertion below — every views[0].order column resolves to a real frontmatter field in the sibling schema.json.

Goal

The originating task T-781K-add-obsidian-bases-setup-flag shipped one obsidian-index.yaml per entity (sibling to schema.json), and /sdlc:setup --obsidian copies the template bytes verbatim into docs/planning/<plural>/<plural>.base. AC-2 of the originating task asserts every views[0].order column maps to a real frontmatter field or a documented file.* / formula.* reference — but that assertion is currently a one-off python -c invocation with no committed test. Drift between a obsidian-index.yaml and its sibling schema.json (typo in a column name, removed frontmatter field) would only surface when a user opens the generated .base in Obsidian. A small lint inside /project-check would catch this on every PR.

Today

Location	Role today
.claude/skills/project-check/check_entity_bases.ts	shells to plugin/validators/validate_base.ts against every plugin/lib/model/entities/*/obsidian-index.yaml and surfaces YAML-parse failures. Does NOT assert views[0].order columns map to real frontmatter fields.
plugin/validators/validate_base.ts	the underlying YAML validator the check delegates to. Returns 0/1/2 — parse success / failure / setup error.
plugin/lib/model/entities/*/obsidian-index.yaml	one shipped template per entity. Each has a views[0].order list — drift between a column name and the sibling schema.json would only surface when the user opens the generated .base in Obsidian.
.claude/skills/project-check/SKILL.md	lists the project-check entry points. Documents check_entity_bases.ts as the base-template check.

Proposed

Extend .claude/skills/project-check/check_entity_bases.ts so that beyond YAML-parse validation, it also asserts — for every plugin/lib/model/entities/<type>/obsidian-index.yaml:

• At least one views entry has type: table.
• views[0].order is a non-empty list of strings.
• Every column in order is either (a) a real frontmatter field declared in the sibling schema.json, (b) a file.* reference from a small allowlist (file.name, file.path, file.mtime, …), or (c) a formula.* reference.

Reports per-entity diffs on mismatch and propagates a non-zero exit through the existing check.

Approach

1. Extend check_entity_bases.ts (do NOT add a new script — the per-entity-base check already exists; layering schema-column validation on top of YAML-parse validation keeps the check surface coherent). The validator side may need a sibling helper under plugin/validators/ if the column-resolution logic is non-trivial.
2. Build a minimal “valid file.* references” allowlist by reading the columns currently shipped in each obsidian-index.yaml. Document the allowlist inline; revisit when a future task adds formula.* support.
3. No SKILL.md prose change needed (the existing entry already mentions the check) unless the new failure mode warrants a one-line call-out.

Files to touch

Location	Kind	Change
.claude/skills/project-check/check_entity_bases.ts	modify	extend YAML-parse validation with views[0].order column-vs-schema validation.
plugin/validators/	modify	possibly add a sibling helper for the column-resolution logic if it doesn’t fit cleanly in the check script. (Optional — decide during implementation.)
.claude/skills/project-check/SKILL.md	modify	one-line addendum to the check description if the failure mode is notably different from parse failure.

Acceptance criteria

• AC-1: Introducing a typo in any plugin/lib/model/entities/<type>/obsidian-index.yaml (e.g. changing status to statuz in views[0].order) causes .claude/skills/project-check/check_entity_bases.ts to exit non-zero with a message naming the offending entity and column.
• AC-2: With all current obsidian-index.yaml files unmodified, check_entity_bases.ts exits zero (no regression in the existing parse-validation path).
• AC-3: Removing a frontmatter field from a schema.json that’s still referenced from its sibling obsidian-index.yaml causes check_entity_bases.ts to fail.

Out of scope

• Auto-fixing drift (a future task can extend /sdlc:entities-migrate if useful).
• Validating non-table view types — none ship today.

Dependencies

• none

Discovery context

Spawned by /sdlc:task-work post-mortem of T-781K-add-obsidian-bases-setup-flag on 2026-05-20.

---

← Back to Tasks