Skip to content

Engineering wisdom is write-only: make lessons-learned.md consumed at decision time (or retire + route it) #987

Description

@waleedkadous

SPIR — methodology/mechanism fix.codev/resources/lessons-learned.md is effectively write-only: durable engineering wisdom accretes into it, but nothing consumes it at decision time, so it can't change agent behavior under load. From a downstream-adopter field report, verified against the codev framework.

Problem (verified in the codev framework, not just an adopter)

Every framework reference to lessons-learned.md is producer/prune-side:

  • The SPIR/PIR review phase + porch/prompts/review.mdwrite entries to it.
  • The update-arch-docs skill + MAINTAIN audit/prune it.
  • The porch checks only enforce that the review file has a ## Lessons Learned Updates section — not that anyone reads the lessons.

Nothing reads or injects it at design/spec time, and nothing enforces it. codev's own CLAUDE.md/AGENTS.md don't even carry the voluntary "grep it before designing" line some adopters add. So it's append-only accretion with no consumer — documentation that hopes to be grepped, which under load agents don't do. Concrete downstream failure: a boolean-vs-role auth design miss that a written lesson could never have prevented, because the file isn't read at decision time.

Goal

Make durable engineering wisdom actually consumed at the moment it would change a decision — or retire the file and route wisdom into surfaces that are consumed. Principle: wisdom only changes behavior if it lives in always-on context (role / CLAUDE.md), an executed protocol step, or an enforced check.

Two candidate directions (spec phase to resolve)

A. Inject at design time — surface relevant lessons-learned entries into protocol/role context at spec/design time, or fold them into protocol steps. Hard part: relevance retrieval — dumping the whole file into every spec re-creates the unbounded-accretion problem, so it needs tagging/matching.
B. Retire + route into consumed surfaces — route each lesson by type: behavioral rule → role file / CLAUDE.md or a protocol step; "don't do X" pattern → a prose-presence / contract test; design-time consideration → injected into the relevant design prompt.

Architect's lean: (B) with a dash of (A) — route by type, reserve design-time injection for genuinely design-sensitive wisdom. The spec phase should weigh both and decide; this is a real design fork, not a mechanical fix.

Scope notes

  • Touches protocol prompts/steps (spec/plan/review), role files, possibly a retrieval/injection mechanism, and the MAINTAIN / update-arch-docs producer side.
  • Same family as the broader codev-framework-feedback theme (cf. the multi-architect coordination layer, Multi-architect coordination layer for codev/afx (roster · board · dedup-at-spawn · lifecycle · bounded state · checkout isolation) #984) — but a distinct concern: this is the consumption mechanism for durable wisdom.
  • The adopter cited a research doc arch-md-codev-framework-feedback.md flagging the append-accretion failure mode; that doc is not in this repo's codev/research/ (adopter-side) — re-derive the accretion analysis here if needed.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/protocolsArea: Protocol definitions — distinct from area/porch (orchestration)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions