You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Route the assertion write commands through KbAssertion
Problem
kb-addandkb-editstill write assertions through the genericFrontmattertype and theschema.yaml/frontmatterRulevalidation path, and the four curatorial fieldslast-verified,addressed-by,supersedes, andsuperseded-bylive as untypedextrakeys. The per-typeKbAssertionrecord module already exists, and the siblingkb-update-eventscommand already routes edits throughKbEvent, 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-eventsis the shipped template. The genericFrontmattertype and theschema.yaml/rule engine are not redundant: they remain the substrate for the read and audit path (check,kb-curate,kb-search) and forcapture-eventandkb create. This ticket does not retire them. The only genuinely dead piece is thefrontmatterSchemazod validator, whose sole reference is its own test.Proposed solution
Promote the four fields to typed members of
KbAssertion, mirroring howKbEventtypesaddressedByandimpact. Routekb-addandkb-editthroughparseAssertion/renderAssertionplusnote-io, droppingloadSchema/frontmatterRule/writeFrontmatter, askb-update-eventsdoes.renderAssertionemitting only declared fields is what keeps an edit from injecting a foreign key.kb-retrieveis not migrated: it keeps reading through the sharedkb-searchlayer, matchingkb-retrieve-events. Delete the deadfrontmatterSchema(validator, test, and re-exports); keep theFrontmattertype and the schema/rule engine.Follow-up (separate ticket): migrate
capture-eventoff the rule engine the same way, so both add-commands share one validation path.Acceptance criteria
Must have
kb-addandkb-editread and write assertions throughKbAssertion(parseAssertion/renderAssertion), not the genericFrontmatterplusschema.yamlvalidation path.last-verified,addressed-by,supersedes, andsuperseded-byare typed fields onKbAssertion, accessed as typed fields by the write commands rather than asextrakeys.updatedbehavior is preserved:verifyleavesupdatedunchanged,add-addressed-bybumps it, andsupersede-withbumps both notes and adds thedeprecatedtag.frontmatterSchema, its test, and its re-exports are removed with no remaining references. TheFrontmattertype and theschema.yaml/rule engine remain.kb-addandkb-editskill docs are updated where they describe schema-based validation and theschema-validationerror, since the commands now validate against theKbAssertioncontract rather than.kb/schema.yaml.