638 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	b3e6a27dc1	docs(6209): forge, dedup, tuning, registry, reply shapes and discipline, checkpoint, lesson kind tests ... Eight more test files state their properties without issue, milestone, rule and decision numbers. The tuning and suspension notes describe the symptom a shipped default or a late ledger produces instead of one install's dated readings; the reply-discipline and checkpoint docstrings state the failure they prevent instead of the session that measured it. test_empty_selector_is_the_rule_115_baseline is renamed for what it checks: the no-forge baseline. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-21 21:30:54 -04:00
bvandeusenandClaude Opus 5.5	0e658bf275	docs(6209): task document, query scrubbing, note pipeline, lesson door, live body, ledger clear, rule usage ... Seven more test files: docstrings and comments state the property and its reason, the SQL-twin note states why `\m` and not `\b` without the install it broke, and fixture provenance says "real near-miss queries" rather than naming the spike that collected them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-21 21:29:49 -04:00
bvandeusenandClaude Opus 5.5	17e1931c0b	docs(6209): rulebooks, pull telemetry, lesson usage, duplicate arm, cited status, trigger shape ... Six more test files state their pinned properties without the issue and milestone history: the pull-telemetry guard explains enumerating kinds instead of listing two getter incidents, cited-record status explains why a hint's id needs its status instead of recounting one misreported step, and the trigger-shape guard keeps its reasoning about why prose heuristics fail while dropping the dated corpus audit. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-21 21:28:35 -04:00
bvandeusenandClaude Opus 5.5	ff08500128	docs(6209): wide net, startup, stamps, slippage, miss route and parity tests ... Eight more test files state the property they pin as a present-tense fact. Incident narratives (a dated storage stall, a week of zero tuning events, a two-project poisoned ledger, a twenty-site owner audit) become the failure shape each test defends; one-install figures that name a rule become a general worked example with the calibration numbers kept. The family-grouping regression guard is renamed for what it checks. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-21 21:27:17 -04:00
bvandeusenandClaude Opus 5.5	d41e72d26c	docs(6209): twelve more test files say which behaviour they pin ... shape ledger, MCP projects/search/rulebooks tools, backup, chunking, plugin context, derived mirror, rule band, shape form gate, plugin version mint and note usage tests drop issue, milestone and rule numbers, dates and one-install figures from docstrings, comments and messages. Three shape-form-gate test names that told the discovery story now name the property: a registry module's helpers are not service functions, the divergence gate silences only a family contradiction, and callable helpers beside a callable canon still prompt. The rulebook tool-count comment that logged each milestone's additions is replaced by the reason it is a count. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-21 21:24:50 -04:00
bvandeusenandClaude Opus 5.5	91c96a8b8a	docs(6209): coverage, guidance-ownership, shape, warnings tests and shared fixtures ... test_pattern_coverage, test_guidance_ownership, test_integration_shape_classify, test_instruction_surfaces_agree, test_retrieval_warnings, helpers.py and conftest.py state the property each test or fixture holds. The issue and milestone numbers, consolidation dates and one-install measurements that recorded how each was found are dropped; fixture dates and ids stay. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-21 21:21:52 -04:00
bvandeusenandClaude Opus 5.5	8518afb54d	docs(6209): rule usage, write path and telemetry tests state the behaviour they pin ... Docstrings, comments and assertion messages in the three most-cited test files now say which property each test holds and why, without the issue, milestone or rule numbers, dates and one-install measurements that recorded how each property was discovered. Fixture ids and calibration scores stay. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-21 21:18:47 -04:00
bvandeusenandClaude Opus 5.5	17777e9bb1	docs(6204): shipped instruction text describes the product, not this instance's records ... MCP tool docstrings and comments, the server's orientation notes, the plugin skills, every hook script and the plugin README/PACKAGING drop record ids, milestone numbers, dates and incident stories, and state each non-obvious why as a present-tense fact. History stays in the task logs. Corrections found on the way: - plugin README/PACKAGING said every hook is a GET; moment, rule-opened and reply-rules POST, so the plugin's key needs write scope. Both now say so, name Settings -> MCP Access, and list every wired hook and endpoint. - the contract-change hint printed "(lesson #4207)", this instance's record, to every install. It no longer cites a record. - tasks.py claimed there is no delete_task; there is. - rulebooks.py cited delete_event and a design spec that no longer exist. - scribe_after_write.sh carried an always-empty etag_q; removed. - test_write_path_trigger pinned "| tac | scribe_defs | head -1", text that existed only in a comment about the old code; it now pins the real tail -1 pipeline. - docs/development.md: CI runs on Gitea Actions. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-21 19:45:09 -04:00
bvandeusenandClaude Opus 5.5	cba2c24612	feat(544): shipped compose files run on the orchestrator's defaults; the app waits for its database itself ... Brings the three compose files in line with rule 198 (milestone 544, step 6203, at the operator's request): - no healthcheck on the app or the database, so a slow pg_isready on stalled storage can no longer get a working database killed; - no deploy.restart_policy in the Swarm file, so Swarm's default (condition: any) restarts clean exits too, instead of on-failure with max_attempts leaving the app down; - depends_on is plain start order; restart: unless-stopped stays on the plain-Compose files (Swarm ignores it), and the dev app gains it. The orchestrator used to be what retried a container that started before Postgres was ready. That is now the app's job: alembic/env.py calls services/db_ready.wait_for_database before migrating. It retries refused connections, unresolved hosts, connect timeouts and "the database system is starting up" with 1-2-4-...-10s spacing for up to 300s, then exits non-zero; a wrong password or missing database fails at once. Per-request recovery is the engine's pool_pre_ping. Also fixes the dev compose database image: postgres:16-alpine has no vector extension, so migrations could not run against it. It now uses pgvector/pgvector:pg17 like the other two files. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-21 19:15:20 -04:00
bvandeusenandClaude Opus 5.5	38d02d9c6f	fix(523): the backup carries user_profiles - the Profile page travels with its user (#5879) ... Settings -> Profile (name, role, expertise, response style, tone, interests, working hours) is typed by its user and neither derived nor a credential, yet _NOT_INCLUDED named it, so a restore dropped it without a word. BACKUP_VERSION 26. Both exports carry it; the restore remaps only the user, and a blank field stays blank rather than restoring as the page's default. The column and import guards cover it, and the tar round-trip restores one. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-15 19:55:52 -04:00
bvandeusenandClaude Opus 5.5	07bc51b890	feat(523): forge-connection tokens are stored sealed under SECRET_KEY, like the backup S3 secret ... The column becomes token_sealed (migration 0122 seals existing rows with a frozen copy of the v1 key), every reader opens it through connection_token, a row this instance cannot open is skipped with a warning, and Settings asks for that token again. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-15 18:08:11 -04:00
bvandeusenandClaude Opus 5.5	b45fc9efba	feat(523): restore reads the backup tar; python -m scribe.restore brings a fresh instance back ... The restore route takes the tar as a raw body beside the JSON download. scribe/restore.py reads either format, refuses a database that already has an account (a restore re-creates everything with new ids, so into a live instance it would duplicate rather than replace), has no size limit, and says to restart so search indexes rebuild. An integration test restores a written tar through the real restore_full_backup and checks every id is remapped. docs/backups.md explains the file, why it is uncompressed, both destinations, Fabled Archives as the worked example, and restoring. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-15 17:40:24 -04:00
bvandeusenandClaude Opus 5.5	4248b450ea	feat(523): the backup job - an hourly tick that runs at the chosen hour, Back up now, and the last 30 runs ... services/backup_job.py reads its config when it fires, so startup reads nothing (#4181) and a changed hour needs no reschedule. A run is held to a 60-minute deadline (a hung NFS mount would otherwise hold the lock and skip every later backup), never runs twice at once, and keeps its outcome - file, size, duration, or the reason in words - in the bounded backup_runs setting, which no backup carries. summarise() gives the page its verdict: overdue when on and no success for 26h. Admin API: GET/PUT /api/admin/backups, POST /backups/check (tests unsaved form values, 45s deadline), POST /backups/run (202, background). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-15 17:34:01 -04:00
bvandeusenandClaude Opus 5.5	ff4f2ee5c2	feat(523): backup destinations - a folder or an S3 bucket, with the S3 secret sealed and kept out of backups ... services/backup_s3.py is FabledSteward's SigV4 client ported (put + list, never delete, so an append-only key is enough), with its tests against AWS's published signatures. services/backup_destination.py holds the admin config (backup_config JSON) and delivers a dated tar to a mounted folder or a bucket, and checks either without sending a backup. services/secrets.py seals the S3 secret with Fernet under a key derived from SECRET_KEY; backup._SETTINGS_NOT_EXPORTED keeps it out of every backup. cryptography becomes a direct dependency (already in the image through pyjwt). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-15 17:31:08 -04:00
bvandeusenandClaude Opus 5.5	1942a7a336	feat(523): the backup as an uncompressed tar of per-table JSON Lines, ordered so restic dedupes it ... export_full_backup orders every query by primary key: an UPDATE moves a row to the end of the heap, so an unordered export shifted every byte after an edited row. services/backup_file.py writes the payload as one dated tar per run - manifest.json plus <section>.jsonl, sorted keys, fixed member headers - atomically via a dot-prefixed .part file, and reads it back into the dict restore_full_backup takes, refusing a missing or short section. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-15 16:30:16 -04:00
bvandeusenandClaude Opus 5.5	69dddb7551	feat(500): Settings shows the shipped reply shapes, what adjusts each, and how often each arrives ... Settings > General > Reply shapes. One menu row per shape (core, completion, asks, plan): its title and when it arrives, how many of the operator's preferences adjust it, and its deliveries over 30 days (in full / as a reminder, "—" when the counts cannot be read). A verdict line leads. Opening a row shows the shipped text, read-only because it is product, and the preferences mounted on its moment; each opens in the rule editor, and "Adjust this" opens a new preference already mounted on the shape's moment with a starting trigger. The rule editor takes an optional preset (kind, moments, trigger) and, opened outside the Rules view, asks where a new record lives instead of dropping it. GET /api/retrieval/reply-shapes now returns reply_shapes.overview: the catalog plus mounted preferences (the same lookup that delivers them) and counts from the reply_shape delivery rows. #5497 (step 5 of milestone 500). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-09 16:19:45 -04:00
bvandeusenandClaude Opus 5.5	b00dc7c4c2	feat(500): reporting-back becomes the long-form reference behind the delivered shapes ... The reply shapes are server product now, delivered at their moments, so the skill stops restating them. Gone from it: the "Every reply" list, the per-kind tables, and "The operator's own shapes come first" (preferences arrive beside the shape on the same moments). It opens by saying where the shapes come from (list_reply_shapes, the delivered core's header) and keeps the reasoning: sections chosen not filled, a settled decision acted on, placement from the record, who decides what, the assumptions an option carries, the completion report worked in full, and the second pass. 13.5k to 10.7k characters. The core gains the Finding kind the skill's table carried (2,150 of 2,200). Tests follow the content: the kind and Approval-row pins move to the shapes, a new test holds the worked example and the completion shape to the same sections, and the guidance-ownership registry reads the delivered shapes as a surface, owning the preference-wins and length topics there. using-scribe points at the delivery and list_reply_shapes. #5496. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-09 15:55:02 -04:00
bvandeusenandClaude Opus 5.5	f68b73f922	feat(500): retire the fixed-question preference arm - completion-report preferences ride the moments ... report_preference searched one constant string when a task closed and handed matches back as update_task's reply_preferences. Milestone 500 step 3 delivers the reply shapes and the preferences mounted beside them on the moments, so the arm goes, whole (rule 22): - services/reply_preferences.py, the REPORT_PREFERENCE RuleArm, its re-scorer and corpus entries, and the REPORTPREF constants - update_task's reply_preferences block and its cue; the docstring now points at moment_rules - the fixed_query field and the fixed_query_never_clears warning: this arm was the only one that set it, so the concept and the cannot_decline exemption go with it - the two Settings fields for its floor and budget - migration 0121 deletes its rows (logs, judgments, rule-usage events, tuning history, settings keys), operator-approved 2026-10-09. Without it the readout would call the source unregistered and its surfacings would count as ambient. The unindexed rule_usage delete is bounded by created_at. #5496 (step 4 of milestone 500). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-09 15:51:04 -04:00
bvandeusenandClaude Opus 5.5	cee1eb1328	fix(500): the section-hold marker is a ledger by name, so a compaction sweeps it ... The marker scribe_reply_check.sh writes after a completion-section hold sat in the swept ledger directory as `<sid>.reportcheck`, and the sweep matches `.ids` - test_every_session_file_in_a_swept_directory_follows_the_convention caught it (run 799). Renamed `<sid>.reportcheck.ids` and added to the roster. #5496. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-09 15:42:25 -04:00
bvandeusenandClaude Opus 5.5	6071007fe2	feat(500): one end-of-turn request - the completion-section check folds into the reply check ... The Stop hook sent the finished reply twice: scribe_report_check.sh checked a task-closing reply for the completion sections in shell and reported to /report-check, and scribe_reply_check.sh sent the same reply to /reply-rules for the rule hold. Now the reply goes once. When the turn closed a task the hook adds the close count and ids, and the server runs the section check (services/report_check, the same three patterns) beside the reply hold, folding both into one reason. The report_check adherence log is still written for every checked reply (milestone 409's number). A section hold marks the session, so its rewrite is sent back once with rewrite:true to record how it came out, and is never held. The block reason carries the completion shape's one line and points at list_reply_shapes rather than at the skill. #5496 (step 4 of milestone 500). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-09 15:38:17 -04:00
bvandeusenandClaude Opus 5.5	ae66d83213	fix(500): the hooks decode a \u escape to UTF-8 in any locale and any awk ... scribe_json_unescape wrote each escaped code point with sprintf("%c", n), which writes the character only under gawk in a UTF-8 locale; gawk in the C locale and mawk in any locale write the single byte n % 256. The server escapes every non-ASCII character, so "·" reached the session as 0xB7, "—" as 0x14 and an emoji as a NUL wherever a hook ran without a UTF-8 locale. The decoder now encodes UTF-8 itself under LC_ALL=C. A new test sends what the server sends from a bare environment, in three locales (#5495). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-09 14:50:29 -04:00
bvandeusenandClaude Opus 5.5	eadb08c347	feat(500): reply shapes are delivered - the core every turn through the ledger, each slice at its moment, reply mounts before the reply (#5495) ... - Every turn (/api/plugin/retrieve, UserPromptSubmit): the core reply shape leads the payload - in full the first time, as its one-line reminder after that - followed by whatever is mounted on reply.report, under the shared rule ledger. Fresh keys come back as shape_keys. - The ledger is <sid>.shapes.ids in scribe-priorart (scribe_shapes_file / _seen / _append), so the compaction sweep that clears every .ids ledger is what brings the full core back after one. - At a moment (/api/plugin/moment): the slice for that reply - completion on work.finish, asks on reply.ask, plan on work.plan - ahead of the mounted rules. reachable_tools now lists tools reaching a shaped moment even on an install with nothing mounted. - Scribe's own tools (attach_moment_rules): reply_shape in the response, in full, since that door has no ledger. enter_project carries the core for clients with no prompt hook. - Telemetry: one AppLog row per delivery (plugin / reply_shape), each shape with full or pointer and the door (turn, hook, mcp). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-09 14:45:25 -04:00
bvandeusenandClaude Opus 5.5	9fedcbea3d	feat(500): who decides what - the agent settles what only it can see, the operator decides direction (#5494) ... The operator's line (2026-10-09), reconciling their 2026-09-21 ruling (#4218, "you are the judge") with "not that Claude should make all decisions": judging covers the work and its records - facts, findings, measurements, whether work is done - and direction stays theirs: priorities, what the thing should be, trade-offs only they can price, anything they live with, and every act hard to undo or facing outward. - reply_shapes: a one-line form in the core (every turn), the full text in the asks slice (where a question gets handed back). Slice budget 1400 -> 1600 for it. - reporting-back "You are the judge": "the operator reads the decision - they do not make it" replaced; the line is drawn by who can see the evidence, not by how hard the call is. - plugin version minted. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-09 14:35:55 -04:00
bvandeusenandClaude Opus 5.5	a0390d9da7	feat(500): the reply shapes become server product content - a compact core and per-kind slices, each tied to its moment (#5493) ... services/reply_shapes.py is the single source of the default reply shapes: the core (every reply, ~1,800 chars against a 2,200 budget) and three slices - completion on work.finish, asks on reply.ask, plan on work.plan. Read through list_reply_shapes (MCP, read-only) and GET /api/retrieval/reply-shapes, one service behind both doors. Nothing delivers them yet; that is step 3. The skill still carries its copy until step 4 shrinks it to the long-form reference. The software-only vocabulary guard moves into tests/helpers.py (DEV_ONLY, dev_only_hits) rather than becoming a fourth copy. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-09 14:29:44 -04:00
bvandeusenandClaude Opus 5.5	37ca2ee958	fix(lessons): convergence is measured against each lesson's own register, and its members must resemble each other - a flat band of no-rule lessons names nothing (#5193) ... Lessons share one register, so any two score well above unrelated text and a fixed similarity bar sat inside that band: every no-rule lesson "resembled" most of the others and the named group grew with the pool. A neighbour now counts only when it stands above the lesson's own background (median and MAD of its similarity to every lesson it can reach, in that register's spread), and a group is a clique: every pair clears the bar from both sides, so one broad lesson cannot join unrelated ones. The bar, the minimum background and the fetch sizes are stated as defaults. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 22:58:39 -04:00
bvandeusenandClaude Opus 5.5	890c93e126	feat(scripts): measure_duplication - the DRY close-out measure: before/after duplicate share, and the copies that exist only after (#4745) ... A multi-pass DRY audit could not answer whether it created duplication: a pass's own shortening can leave two statements identical to a third, and no per-pass scan sees a copy that did not exist when it ran. The Librarian retrospective improvised this measure in a scratchpad; this is it as a tool the DRY Pass process can name. 6-line windows over significant lines (comments, blanks and bare punctuation dropped, strings folded), grouped by glob or extension. Revisions are read through git archive, so nothing is checked out. Stdlib only, so any project can run a scratch copy. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 21:24:05 -04:00
bvandeusenandClaude Opus 5.5	5323a1fbc2	fix(family): the repeat trigger compares a record only with its own kind - a snippet with snippets, a note with notes (#5130) ... A dated release log (a note) matched a signed-APK CI snippet at 0.83 on shared release vocabulary and was opened as a family candidate, then came back as a precedent. One chunk of a long narrative scores like the shape it mentions, so a cross-kind score does not mean "the same thing made twice". The search is filtered to the new record's kind and the loop checks it too. Code built from an idea written elsewhere still reaches the engine through the citation trigger and the shape ledger. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 18:32:55 -04:00
bvandeusenandClaude Opus 5.5	f006f15058	fix(family): a decision read as precedent says its reason once - to_brief for precedents and idea history; the decision log keeps the full row (#5131) ... Each decision stored its reason three times (reason, before.reason, after.reason) and a promotion carried the whole criteria reasoning in evidence. Precedents (assess, promote, get_family_adoption, get_family_idea) and get_family_idea's history now serve FamilyDecision.to_brief(): reason once, before/after as status, canon_version and platforms, evidence as the cited list. list_family_decisions and the decision echoed back by a write keep to_dict. The precedent count was already bounded at five. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 18:30:48 -04:00
bvandeusenandClaude Opus 5.5	07169e1274	feat(family): an idea links to the rule topic holding its norms - set_family_topic, the readouts name the rules, the idea row shows the link (milestone 463 step 1 gap, found in step 7, #4993) ... Step 1 added family_ideas.topic_id but nothing could set it, so the note<->topic link the milestone promised existed only as a column. set_family_topic links or unlinks (0) a topic in a rulebook the caller owns, one idea per topic; the version does not move. get_family_idea and get_family_adoption list the topic's rules; list_family_ideas and the Family page name the topic. The model docstrings no longer claim the topic's rules are platform-scoped in retrieval. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 14:27:33 -04:00
bvandeusenandClaude Opus 5.5	b8efff43b4	fix(family): the reach tests assert on their own corpus; the shared integration database holds other tests' canon on the same platform (#4992) ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 13:35:42 -04:00
bvandeusenandClaude Opus 5.5	07e21c7ff9	feat(family): family canon reaches the session - entry readout, retrieval reach, skill, report cue (milestone 463 step 6, #4992) ... - 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>	2026-10-06 13:27:39 -04:00
bvandeusenandClaude Opus 5.5	5f41dbd283	feat(family): the shape ledger judges against family ideas, across languages (milestone 463 step 5, #4991) ... - 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>	2026-10-06 13:06:45 -04:00
bvandeusenandClaude Opus 5.5	233fa3eea9	fix(family): the owed task is tagged by the matching System only, and the ground fixtures build without duplicate keys (#4990) ... 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>	2026-10-06 11:11:41 -04:00
bvandeusenandClaude Opus 5.5	201e09901b	feat(family): the adoption ledger - assessment, the conflict order, owed->task, recheck, the adoption matrix (milestone 463 step 4, #4990) ... - 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>	2026-10-06 11:05:00 -04:00
bvandeusenandClaude Opus 5.5	8aacc1824c	feat(family): the promotion engine - triggers, the three criteria, the decision log and undo (milestone 463 step 3, #4989) ... 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>	2026-10-06 10:33:30 -04:00
bvandeusenandClaude Opus 5.5	1774ee3696	fix(frontend): each shared <style src> sheet sits at one block index everywhere, so vite build cannot depend on transform order (#4988) ... 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>	2026-10-06 09:58:41 -04:00
bvandeusenandClaude Opus 5.5	07d2542479	feat(family): platforms declared at inception and detected from bound repos (milestone 463 step 2, #4988) ... 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>	2026-10-06 09:51:28 -04:00
bvandeusenandClaude Opus 5.5	e68ccc5884	feat(family): platforms, family ideas, the adoption ledger and its decision log (milestone 463 step 1, #4987) ... 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>	2026-10-06 09:33:27 -04:00
bvandeusenandClaude Opus 5.5	ccbccb025c	fix(retrieval): every semantic search scopes first, then ranks - the note, milestone and system searches join the rule search on one shared shape, _rank_scoped (#4961) ... Ordered straight off a *_embeddings table, the planner walks the HNSW index, takes ~ef_search (40) nearest chunks across every owner and project, and only then applies the scope: an in-scope record behind 40 nearer ones the caller cannot see was silently dropped. #4958 fixed the rule search alone; the note, milestone and system searches kept the fault. _scoped_chunks builds the in-scope chunks with their distance; _rank_scoped materializes them as a CTE and ranks exactly. All four searches go through it, and the row shape is unchanged, so callers and mocks are untouched. Tests: a structural guard that every semantic_search_* ranks through _rank_scoped and orders nothing itself (with a replay of the old shape), a compiled-SQL check of the MATERIALIZED CTE, and integration crowd tests - 80 nearer out-of-scope records - for notes (another user; the reader own other project), milestones and systems. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-05 21:08:45 -04:00
bvandeusenandClaude Opus 5.5	d2fa723373	refactor(retrieval): the rule builders compose one moment - _rule_moment runs the arm and its via-lesson step for all three (milestone 456 step 6, #4908) ... build_prompt_rule_hint, build_tool_rule_hint and build_write_path_hint each ran the rule arm and then the via-lesson step by hand, the first two passing the query between them through a _via_query key on the payload. They now call one composer, _rule_moment, and the split helpers (_prompt_rule_hint, _tool_rule_hint, _add_rules_via_lessons) and the side channel are deleted. Output shapes are unchanged: the prompt builder returns no checkpoint key, the tool builder always does, and shown_rule_ids stays the direct band. A structural test pins that only _rule_moment runs a rule arm or the via-lesson step, and that the three builders are its only callers. plugin_context.py: 2,418 -> 2,361 lines this step; 3,558 when the milestone began. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-05 20:25:47 -04:00
bvandeusenandClaude Opus 5.5	869046dda2	refactor(retrieval): the specs are the registry - SURFACES, the ranked POINTS rows and RANKED_SOURCES are read off the pipeline specs (milestone 456 step 5, #4907) ... Each arm spec now carries its tuning pair (Surface, moved verbatim into retrieval_pipeline) and a Declared block - what the telemetry readout must know and cannot read off its rows. The two ranked stages that are not arms (preference_slot, rule_via_lesson) are RankedSource specs, and the note slots carry their own declaration. - retrieval_surfaces.SURFACES = the TUNED_ARMS tuning, same order - retrieval_registry.POINTS ranked rows = one per spec in RANKED; the lookups, asked, ambient and pull rows stay declared there - rule_usage.RANKED_SOURCES = RULE_RANKED_SOURCES + moment_rule Settings keys, defaults, prose and order are unchanged (checked field by field against HEAD). tests/test_retrieval_specs.py pins the derivation. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-05 20:11:20 -04:00
bvandeusenandClaude Opus 5.5	2b8f41229d	refactor(retrieval): the notes arms run on the one pipeline - auto_inject, its reuse and lesson slots, the write path by meaning, and rule_via_lesson are specs (milestone 456 step 4, #4906) ... retrieval_pipeline gains the notes half: NoteArm / NoteSlot / NoteMoment / NoteIO / NoteResult and run_note_arm, which writes once the stages both notes arms copied: search, withhold this response's own menu (#3739), fresh/repeat split, the call row before any return (#3497, #3752), the band, the reserved slots in their order (reuse evicts, lesson extends), and the surfacing rows. The note renderer (_record_kind, _menu_name, _menu_passage, the seen pointer, menu_entry) moves with it, and run_via_lesson_arm takes rule_via_lesson. Behaviour-preserving, with flags for today's differences: notes still log BEFORE the band and rules after it (step 7's question). One deliberate change: a notes arm now fails open like the rule arms, so a failing search costs its lines and no longer the whole hook response. The I/O is resolved from plugin_context at call time (_note_io), so the existing patches keep working. The review re-run reads the AUTO_INJECT spec instead of restating it, and its guard now compares the two live searches. The registry declares the pipeline's notes fan-out sites. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-05 20:02:37 -04:00
bvandeusenandClaude Opus 5.5	4b1060ae8b	Revert the deliberate integration failure - the gate was watched rejecting run 8218 (rule 177, #4958) ... Run 8218: integration failure, Build & push skipped, :dev still package version 11098 (23:36:29Z, run 8217), and no image tagged 9a76eb0. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-05 19:42:04 -04:00
bvandeusenandClaude Opus 5.5	9a76eb0a34	test(ci): TEMPORARY deliberate integration failure, to watch the publish gate reject a red run (rule 177, #4958) ... Reverted next. Expect: integration red, Build & push skipped, :dev unmoved, no image tagged with this commit. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-05 19:38:13 -04:00
bvandeusenandClaude Opus 5.5	983fd2c4d1	fix(retrieval): scope the rule search before ranking it - an in-scope rule is no longer lost behind other owners' nearer rules (#4958) ... Ordered straight off rule_embeddings, the planner walked the HNSW index, which returns about hnsw.ef_search (40) nearest chunks across every owner and project and filters by home only afterwards. A reader's own rule ranked past the 40th chunk overall was silently dropped - on a shared install, other users' rules fill those 40. This is the likely cause of the intermittent test_integration_rule_scope failures, whose axis-vector fixtures sit far from every real embedding in the graph. The in-scope chunks now go through a MATERIALIZED CTE, which the index cannot order, so the ranking over them is exact. A rulebook is hundreds of chunks; exact is cheap. New test: 80 nearer rules belonging to someone else no longer hide the reader's one rule. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-05 19:30:05 -04:00
bvandeusenandClaude Opus 5.5	79cd2341a6	test(rules): the scope test says why a rule search returned nothing - an error or an empty scan (#4958) ... semantic_search_rules fails open, so both failures on run 8209 and main run 8212 read as set() with no trace. Assert report["searched"] and carry the swallowed traceback into the failure. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-05 18:34:16 -04:00
bvandeusenandClaude Opus 5.5	4e1320120d	feat(moments): a mount that keeps arriving where it does not apply proposes its own removal (milestone 458 step 7b, #4955) ... The open-after-moment signal proposes a mount; nothing proposed taking one off, so a wrong mount was noise at every occurrence until someone happened to notice. rule_misfired(rule_id, moment, why, reached_by) records a report against a MOUNTED pair, counted per distinct day (the MCP door carries no session id) on a new rule_moment_judgments.misfire column (migration 0119, backup v24). At three days the response carries a line asking the agent to offer the operator the fix - reject takes the rule off, unmap_action stops the action reaching the moment, confirm keeps the mount and stops the asking - and Settings > Moments lists it as an unmount proposal with the reasons and the actions that reached it. A re-mount clears the count. Taught in moments.md, missed-retrieval.md and the reply hold's wording. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-05 18:19:59 -04:00
bvandeusenandClaude Opus 5.5	a72a422534	docs(plugin): the instruction surfaces teach moments - reading a line that arrived at one, correcting a misfire, and giving a new rule its moments (milestone 458 step 8, #4926) ... Until now only the tool arguments knew moments existed. The guidance surfaces described rules as reached by resemblance alone: - using-scribe: a short reflex paragraph and a new reference file, moments.md. It covers reading "at <moment>, reached by <action>", the reply held once at reply.report, map_action / unmap_action offered in one line, and the step 7 proposal line answered with judge_rule_moments. - writing-records: asks WHEN a rule applies as well as what it is about. A rule, preference or process about a point in the work gets moments=[...] as it is written, and the trigger stays as the net. - missed-retrieval: a missed WHEN is mounted or mapped, not reworded. A misfire is unmounted or unmapped. - _INSTRUCTIONS: one clause (list_moments; mount rules about WHEN), 1594 of 1600 chars. - static context: injected lines include the rules mounted on a moment that was reached. - test_guidance_ownership: three owned topics, so the text cannot quietly drop out. Plugin minted. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-05 16:39:47 -04:00
bvandeusenandClaude Opus 5.5	c404a3127a	test(retrieval): the proposal endpoints are routed on the app (milestone 458 step 7, #4925) ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-05 16:16:59 -04:00
bvandeusenandClaude Opus 5.5	570d1b6d5a	test(backup): register the rule_moment_judgments builder in the import column guard (milestone 458 step 7, #4925) ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-05 16:12:30 -04:00