Merge dev: family canon, milestone 463 steps 1-6 #206

Merged

bvandeusen merged 10 commits from dev into main 2026-10-06 14:11:29 -04:00

Conversation 0 Commits 10 Files Changed 72

+9131 -130

bvandeusen commented 2026-10-06 14:11:25 -04:00

Owner

Copy Link

Copy Source

Merged because the operator asked for it. Step 7 (#4993) is acceptance on the live instance, and it needs these tools served there.

What's in it (10 commits, e68ccc5..b8efff4; CI green on b8efff4, run 8341):

• Step 1 (#4987). Platforms catalog, family ideas, the adoption ledger and its decision log. Migration 0120 adds new tables only.
• Step 2 (#4988). Platforms are declared at inception and detected from bound repos. Also a vite build-order fix for shared <style src> sheets.
• Step 3 (#4989). The promotion engine: triggers, the three criteria, the decision log and undo.
• Step 4 (#4990).
  • Assessment and the conflict order.
  • An owed answer files a task in the owing project.
  • Answers on an older canon version are flagged for recheck.
  • The adoption matrix, in the UI and over REST.
• Step 5 (#4991).
  • The shape ledger judges code against family ideas, across languages.
  • The adoption ledger follows the shape ledger.
  • The proposer has a measured family arm.
• Step 6 (#4992).
  • enter_project carries a family readout.
  • Widened retrieval reaches family ideas on a shared platform.
  • Closing a task returns family_owed.
  • New plugin skill family-canon; plugin version 2026.10.06.1726.

After merge:

• Redeploy so migration 0120 runs.
• Refresh the plugin to 2026.10.06.1726.

🤖 Generated with Claude Code

Merged because the operator asked for it. Step 7 (#4993) is acceptance on the live instance, and it needs these tools served there. **What's in it** (10 commits, e68ccc5..b8efff4; CI green on b8efff4, run 8341): - **Step 1 (#4987).** Platforms catalog, family ideas, the adoption ledger and its decision log. Migration 0120 adds new tables only. - **Step 2 (#4988).** Platforms are declared at inception and detected from bound repos. Also a vite build-order fix for shared `<style src>` sheets. - **Step 3 (#4989).** The promotion engine: triggers, the three criteria, the decision log and undo. - **Step 4 (#4990).** - Assessment and the conflict order. - An `owed` answer files a task in the owing project. - Answers on an older canon version are flagged for recheck. - The adoption matrix, in the UI and over REST. - **Step 5 (#4991).** - The shape ledger judges code against family ideas, across languages. - The adoption ledger follows the shape ledger. - The proposer has a measured family arm. - **Step 6 (#4992).** - enter_project carries a `family` readout. - Widened retrieval reaches family ideas on a shared platform. - Closing a task returns `family_owed`. - New plugin skill `family-canon`; plugin version 2026.10.06.1726. **After merge:** - Redeploy so migration 0120 runs. - Refresh the plugin to 2026.10.06.1726. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

bvandeusen added 10 commits 2026-10-06 14:11:25 -04:00

feat(family): platforms, family ideas, the adoption ledger and its decision log (milestone 463 step 1, #4987) ... e68ccc5884

When one project solves something every project on the same platform will
meet, that solution becomes family canon and every other project on the
platform answers it. This is the storage for that.

- platforms: a global catalog in the canonical_systems shape, seeded with
  generic technology names and the file markers step 2's detection reads.
- project_platforms: declared / detected / rejected. A rejected row is kept
  so detection cannot re-add what a person said no to.
- family_ideas: a note's family state. No new record type; any note, snippet
  or lesson becomes an idea. A canon idea must state when it applies (CHECK).
- family_idea_platforms: the only scope source. A linked rule topic takes its
  scope from the idea, so the two cannot disagree.
- family_idea_references: reference implementations, explicit not inferred.
- family_adoptions: one answer per (project, idea). Variant and exempt require
  a reason (CHECK). Recheck is derived from the two canon versions, never
  stored.
- family_decisions: the append-only log, with a required reason and the
  earlier decisions each one followed. The agent decides with no approval
  step, so precedent is what keeps its calls consistent.

Backup v25 carries all seven: platforms by slug, precedent ids remapped
through the decision map. Both column guards cover the new tables, and a
real-Postgres test exercises the CHECKs and the restore remaps.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

feat(family): platforms declared at inception and detected from bound repos (milestone 463 step 2, #4988) ... 07d2542479

A project's platforms decide which family ideas reach it. This step makes membership answerable from every door:

- services/platforms.py: the global catalog (writes are admin-only and duplicate-gated by slug); pure marker detection; and membership reads and writes. Detection only ADDS, and only where nobody has answered. It never overrides a declared or rejected row and never removes one.
- coverage: the archive scan now carries every path, and the refresh runs detection fail-open.
- inception: a platforms choice (slugs, or null for unanswered). The list is the whole answer: members left out of it become rejected.
- MCP: list_platforms and set_project_platforms; enter_project and get_project carry the project's platforms.
- REST: /api/platforms (admin writes) and /api/projects/<id>/platforms.
- UI: a platforms checklist on the inception card, a Family tab on ProjectView, and a Platforms admin tab in Settings.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

fix(frontend): each shared <style src> sheet sits at one block index everywhere, so vite build cannot depend on transform order (#4988) ... 1774ee3696

Run 8271 failed in the image build: "[vite:vue] Cannot read properties of undefined (reading 'scoped')" on moments-shared.css. plugin-vue caches one descriptor per src file and answers ?index=N from whichever component registered it last. RuleEditorSlideOver had moments-shared at block 2, while its other two importers have it at block 1. Step 2's new imports changed the transform order and exposed the bug.

- RuleEditorSlideOver: moments-shared is now loaded with an @import instead of a third <style src>.
- rules-shared.css sat at block 0 in the five panes and at block 1 in LessonDetailView, LessonEditorView and RuleEditorSlideOver, which is the same latent hazard. The three move to block 0.
- tests/test_frontend_shared_styles.py: a guard that every <style src> sheet sits at one index, plus a test that the guard can fail. vue-tsc cannot see this hazard, and vite build only runs after every test has passed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

feat(family): the promotion engine - triggers, the three criteria, the decision log and undo (milestone 463 step 3, #4989) ... 8aacc1824c

The agent promotes a family idea when all three criteria hold, and no person approves it. The criteria are product text: services/family.py states them, and the promote tool's docstring names every criterion the service enforces.

- Criteria: each one vetoes on its own when its reasoning is blank. Platform terms also needs an applies-when and a platform scope; proven also needs named evidence. A veto keeps the idea a candidate and is logged, so it becomes precedent.
- Precedent: every promotion stores the decisions on the nearest ideas by meaning, plus any the caller names.
- Promotion sets canon, the applicability test and the platform scope, and opens an unassessed ledger row for each member project the promoter can write. Re-promotion moves the version past every version the idea has held.
- Retire and undo: undo reverses only the latest idea-level decision, restores its recorded before-state, and logs itself with the undone decision as its precedent. Settled here: leaving canon closes the unassessed rows but keeps the judged ones, which read as needing a recheck after a re-promotion.
- Triggers open evaluations but never promote:
  - a cross-project lineage citation ("matching #N") on a note or task write;
  - a same-meaning record in another project on a shared platform, on create, at 0.80 (measured: the known pattern's builds scored 0.79-0.82, an unrelated project's best match 0.65);
  - a milestone closing on a platform.
  Each fails open and rides the response as family_hint.
- Doors: seven MCP tools, /api/family REST endpoints, and a Family page (nav, /family) showing the criteria, the ideas, and the decision log with undo and retire.
- utils/recordHref.ts holds the one copy of "where a record opens", now shared with LessonDetailView.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

fix(family): undoing the decision that created an idea leaves no applicability or scope behind (#4989) ... faa1b72307

When the undone decision had no recorded before-state, the synthesized prior copied the canon idea's current applies_when and platforms into a retired row. Before that decision the record was not an idea, so the restored state now has neither. Caught by test_undoing_a_promotion_restores_the_prior_state_and_keeps_judged_rows (run 8281).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

feat(family): the adoption ledger - assessment, the conflict order, owed->task, recheck, the adoption matrix (milestone 463 step 4, #4990) ... 201e09901b

- services/family_adoption.py: assess one project against one canon idea by
  the four outcomes in order (exempt, variant, adopted, owed). Every outcome
  needs a reason and adopted needs evidence. The engine records the precedents
  itself: this idea's answers elsewhere, and this project's answers to the
  nearest ideas. The same answer given twice records nothing.
- owed files a task in the OWING project, tagged to the System matching the
  idea's canonical area, naming the gap and the reference for that project's
  language. The task follows the answer: adopted closes it, exempt or variant
  cancels it, owed again reopens it. Each move is logged on the task.
- the conflict order is enforced: every ground above the deciding one must
  say why it did not decide. The losing side is folded into the idea's note as
  a trap, an alternative or a condition branch, the version moves, and both
  rows are answered against the revision.
- recheck is derived (row version != idea version). family.revise moves the
  version when substance changes. undo covers a project's latest answer too.
- set_family_references names the reference implementations.
- MCP: get/list/assess adoption, resolve_family_conflict, revise_family_idea,
  set_family_references. Web: GET /api/family/matrix.
- UI: an adoption matrix on /family (platform filter, cell detail with reason,
  recheck and owed-task link) and the same matrix narrowed to one project on
  its Family tab. The decision log now reads project-level decisions.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

fix(family): the owed task is tagged by the matching System only, and the ground fixtures build without duplicate keys (#4990) ... 233fa3eea9

assess_family_adoption took system_ids for the task it files, which made
the family tool module look like a System-tagging door and tripped the
parity registry. It is not one: the owed task is tagged to the project's
System matching the idea's canonical area, and update_task retags it.
The unit test for each conflict ground passed evidence/conditions twice.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

feat(family): the shape ledger judges against family ideas, across languages (milestone 463 step 5, #4991) ... 5f41dbd283

- classify_shapes takes idea_id: the shape is judged against the idea's
  reference in its language, or its first.
- A shape classified against a canon idea's reference moves the project's
  adoption row (instance -> adopted, variant -> variant). Withdrawing the
  shapes that gave an answer returns it to unassessed. This runs on
  classify_shapes, the sweep, confirm_proposals and the coverage refresh.
- assess and undo refuse an answer the shapes contradict. A conflict
  resolution re-judges the variant shapes on both sides.
- The proposer's family arm offers a canon idea's reference on a shared
  platform, in any language. It proposes only when the reference is the top
  hit over every readable snippet and scores at least 0.70. The pairs this
  was measured on are recorded beside _FAMILY_FLOOR. The proposer is now v6.
- The matrix cell shows the code that answers it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

feat(family): family canon reaches the session - entry readout, retrieval reach, skill, report cue (milestone 463 step 6, #4992) ... 07e21c7ff9

- enter_project carries a `family` key, but only when the project has
  something to answer: counts of unassessed, owed and to-recheck answers,
  each with the list_family_adoptions call that lists it. It shows on every
  entry, never by platform touch: entry is when work is chosen, and an
  unanswered idea is otherwise invisible.
- Retrieval: a widened project search (include_global_kinds) now also
  reaches the canon ideas on the project's platforms. It also reaches their
  references in the project's languages, or all of them when none matches.
  An off-platform project gets none, and the plain project filter (the
  duplicate gate) is unchanged.
- Closing a task returns `family_owed`, the owed answers filed while it was
  open, and the report cue asks for them to be named.
- New plugin skill family-canon (moment work.record) covers when to
  evaluate a promotion, answering in order, what counts as a reason, the
  precedent reflex and the conflict order. _INSTRUCTIONS, create_note,
  create_snippet, classify_shapes and reporting-back point at it.
  The plugin version is minted.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

fix(family): the reach tests assert on their own corpus; the shared integration database holds other tests' canon on the same platform (#4992) ... b8efff43b4

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

bvandeusen merged commit ecbadf51ce into main 2026-10-06 14:11:29 -04:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

renovate-bot bvandeusen

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bvandeusen/FabledScribe#206