TT Claude Memory

feedback_verify_framework_extension_maintenance_before_lock

Properties1
descriptionDiscipline locked 2026-05-24T21:20 BST after Phase D'' execution-attempt surfaced bmad-federated-knowledge stale-3rd-party finding at §0 PRECONDITION GATE. When scoring framework adoption, the maintenance health of any REQUIRED EXTENSION (not just the root framework) MUST be verified empirically before lock. Path D's 96% scorecard accepted 'BMAD+federation-extension' as a unit without inspecting whether the extension was 1st-party + maintained. Result: a hidden 3rd-party stale-since-2025-09 component became the cornerstone of the lock. Discipline applies forward to ANY framework-adoption scorecard authoring.

3 min read

Rule: when authoring a framework-adoption scorecard, every CAPABILITY criterion that depends on an external extension (npm package, plugin, community preset, sister-framework integration) MUST verify the extension’s maintenance health before scoring. The verification battery:

  1. Author 1st-party check: is the extension authored/maintained by the same org as the root framework? Look at the package’s author: / repository: URL.
  2. Last-published recency: when was the extension last published? Anything >6 months without a release on a fast-moving framework is suspect.
  3. Peer-dep currency: does the extension’s peerDependencies block claim compatibility with the current major version of the root framework? >=4.0.0 on a v6+ framework = pre-v6.x era; may not work.
  4. Dependency footprint review: does the extension pull heavy/risky deps (puppeteer, mongodb, mysql2, pg, sodium)? Each adds supply-chain surface + install footprint.
  5. README-search the root framework’s main README: does the root framework reference the extension as 1st-party? Or is it community/un-vendored? Grep main README for the extension name.
  6. Open-issues/PR count against the extension itself: high count + slow merge = abandoned.

Why this exists (the 2026-05-24 incident):

Path D (BMAD METHOD + OpenSpec hybrid; locked 2026-05-23T19:30 BST after 3-iteration scorecard convergence at 96%) hinged on D-1 lock = “hierarchical BMAD federation via bmad-federated-knowledge extension.” Phase D” execution session 2026-05-24T20:54 BST probed the extension at §0 PRECONDITION GATE and found:

  • Author: vishalmysore (community contributor; NOT BMad Code, LLC)
  • Last published: 2025-09-16 (8 months pre-session)
  • Peer dep: bmad-method: ">=4.0.0" (BMAD is at v6.7.1 today; was at v4.x when extension was written)
  • Heavy deps: puppeteer (Chrome) + mongodb + mysql2 + pg + pdfkit
  • BMAD main README grep: ZERO native federation/multi-repo mentions; extension not vendored

The 96% scorecard treated “BMAD federation” as a 1st-party feature. It wasn’t. Application of the verification battery above would have caught this BEFORE the 3-iteration scorecard locked Path D — the work of locking + authoring 5-commit launch-prompt v1.0..v1.5 + execution-dispatch v1.0 + ~700-line Phase D” substrate would have been redirected earlier to Path E (Spec-Kit alone — empirically validated as the optimal choice on 2026-05-24).

How to apply:

  • Embed the 6-check battery in scorecard authoring as a default discipline (alongside superpowers:brainstorming + closing-question boundary test)
  • Every CAPABILITY column in the scorecard table tagged with [ext: <package>] MUST cite empirical-check results inline (e.g. “[ext: bmad-federated-knowledge@1.0.4; last pub 2025-09-16; community 3rd-party; peer >=4.0.0]”)
  • Pre-execution §0 PRECONDITION GATE includes an npm view <extension> recency probe for every framework-required extension; gates BLOCK if last-publish >6 months
  • Re-scorecard if any extension fails verification — the original scorecard’s CAPABILITY weight is corrupted

Related: feedback-adopt-github-spec-kit (Path E; reinstated 2026-05-24 after this discipline applied retroactively) + feedback-adopt-bmad-plus-openspec-hybrid (Path D; superseded 2026-05-24 by this discipline) + Path E pivot SCF.

Anti-pattern caught: scorecard convergence without empirical extension verification = false 96% confidence; the score is brittle to the dependency-graph health of every required external piece.

Graph View

Backlinks