Skip to content

Route the assertion write commands through KbAssertion #852

Description

@williamthorsen

Route the assertion write commands through KbAssertion

Problem

kb-add and kb-edit still write assertions through the generic Frontmatter type and the schema.yaml/frontmatterRule validation path, and the four curatorial fields last-verified, addressed-by, supersedes, and superseded-by live as untyped extra keys. The per-type KbAssertion record module already exists, and the sibling kb-update-events command already routes edits through KbEvent, so the assertion write path is the last stringly-typed holdout and is inconsistent with the events precedent.

Context

Part of the per-type record architecture epic (#848); kb-update-events is the shipped template. The generic Frontmatter type and the schema.yaml/rule engine are not redundant: they remain the substrate for the read and audit path (check, kb-curate, kb-search) and for capture-event and kb create. This ticket does not retire them. The only genuinely dead piece is the frontmatterSchema zod validator, whose sole reference is its own test.

Proposed solution

Promote the four fields to typed members of KbAssertion, mirroring how KbEvent types addressedBy and impact. Route kb-add and kb-edit through parseAssertion/renderAssertion plus note-io, dropping loadSchema/frontmatterRule/writeFrontmatter, as kb-update-events does. renderAssertion emitting only declared fields is what keeps an edit from injecting a foreign key.

kb-retrieve is not migrated: it keeps reading through the shared kb-search layer, matching kb-retrieve-events. Delete the dead frontmatterSchema (validator, test, and re-exports); keep the Frontmatter type and the schema/rule engine.

Follow-up (separate ticket): migrate capture-event off the rule engine the same way, so both add-commands share one validation path.

Acceptance criteria

Must have

  • kb-add and kb-edit read and write assertions through KbAssertion (parseAssertion/renderAssertion), not the generic Frontmatter plus schema.yaml validation path.
  • last-verified, addressed-by, supersedes, and superseded-by are typed fields on KbAssertion, accessed as typed fields by the write commands rather than as extra keys.
  • Each edit operation's updated behavior is preserved: verify leaves updated unchanged, add-addressed-by bumps it, and supersede-with bumps both notes and adds the deprecated tag.
  • frontmatterSchema, its test, and its re-exports are removed with no remaining references. The Frontmatter type and the schema.yaml/rule engine remain.
  • New and modified behavior in this change is covered by tests.
  • The kb-add and kb-edit skill docs are updated where they describe schema-based validation and the schema-validation error, since the commands now validate against the KbAssertion contract rather than .kb/schema.yaml.

Metadata

Metadata

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions