liquidware-ninjaSecond brain & toolkit
Personal project. Research and learning only. Not for production. No warranty.Not for production
  • Built on my own time for research and learning. Not affiliated with, endorsed by or supported by my employer, Liquidware or Microsoft.
  • Bring your own Liquidware licenses. Don't run any of it in production or against tenants and subscriptions that matter. Test in a dedicated lab first.
  • Provided "as is", without warranty of any kind, under each repository's license. You use it at your own risk and own the Azure charges it incurs.
  • Contributions and forks are welcome and encouraged on public repos. See Contribute.

0011. Family format: a guard field on known errors

proposedReviewed 2026-10-18Source: decisions/0011-family-format-guard-on-known-errors.md

Context and Problem Statement

This project's rule is that every lesson from a real run adds a guard, a test or a check that stops it coming back (0007). The family's known-error entries record symptom, cause, fix and source, but not whether anything now prevents the error. A fixed error with no guard is likely to return. Should the shared format record the guard?

Considered Options

  • An optional guard field on each known error (a repo path to the test or check, or a short description), and the freshness check lists verified entries without one
  • Keep guards in the fix text

Decision Outcome

Chosen option: "An optional guard field", because a separate field can be checked and listed, and an optional one costs KBs without tests nothing.

Consequences

  • Good, because each KB can see which fixed errors could still come back.
  • Neutral, because it's optional, so existing entries stay valid.
  • Bad, because it's a change to the shared schema and freshness script, adopted by PR in every KB.

More Information

A family format change: written here as proposed, then raised with 2ndbrain, which owns the format (2ndbrain). This KB keeps the shared schema unchanged until the family adopts it.

Linked from 2 pages