fix(knowledge): waive source_* requirements for source_kind: internal (and teach the doc generator about it) - #1684
Closed
elhoim wants to merge 1 commit into
Closed
Conversation
PER_TYPE_REQUIRED demands source_url on every research note. That is wrong for notes with source_kind: internal — those have no external origin, they ARE the primary artifact (an own-prose capture, a design decision, a corpus the system itself built). The rule asks for a URL that cannot exist. On a real archive this was 10 notes permanently unable to pass lint, with nothing to backfill: none of the ten had a single URL anywhere in its body. The fix is the schema, not the notes. Skip source_* per-type requirements when source_kind is internal. Externally-sourced notes still must carry their provenance. Also teach GenerateKnowledgeSchemaDoc to emit the waiver. The generator reads PER_TYPE_REQUIRED (a data table) while the rule lives in validate(), so the generated doc would otherwise state a requirement the linter does not enforce — the same doc-vs-behaviour drift this schema exists to prevent.
This was referenced Jul 28, 2026
Owner
|
Ported into source with credit — thank you. The public repo is generated from a private tree by rsync at release time, so a merge here would be reverted at the next cut. Instead the intent landed in source, your handle and this PR number are in the code comment at the fix site, and it ships in the next release. Closing this PR as ported, not rejected. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PER_TYPE_REQUIREDdemandssource_urlon everyresearchnote. That is wrong for notes carryingsource_kind: internal— those have no external origin. They are the primary artifact: an own-prose capture, a design decision, a corpus the system itself built. The rule asks for a URL that cannot exist.Found on a real archive
Migrating a 1,801-note archive onto kb-v3 left exactly two violation classes. The second was 10 research notes failing this rule with nothing to backfill — I checked every one, and none contained a single URL anywhere in its body. Three were LifeOS's own artifacts; seven were OCR captures whose source URL was lost upstream.
Editing ten notes to satisfy a rule that shouldn't apply to them is the wrong direction. Fixing the rule took one condition.
The change
Externally-sourced notes are unaffected and still must carry their provenance.
Second half: the generator
GenerateKnowledgeSchemaDocreadsPER_TYPE_REQUIRED— a data table — while the new rule lives invalidate(). Left alone, the generated_schema.mdwould state a requirement the linter does not enforce.That is the exact failure this schema exists to prevent, so the generator now emits the waiver alongside the table.
Verified
On the archive this was found on:
_schema.mdregenerated and carries the waiver text. One caveat worth stating: my first attempt at this usedfield(), which returns anFmFieldobject rather than a string —KnowledgeLintthrew a TypeError immediately rather than silently mis-validating, which is the behaviour you want from a linter. The committed version usesdeq(get(...)), matching the surrounding code.