@open-tomato/rafa 0.18.0 → 0.19.0

package/README.md

@@ -352,9 +352,9 @@ and never none.
 The build targets bun, and `engines` names `bun` alone: there is no
 `engines.node`, because no node version runs the binary. The package
 root, `./cli` and `./store` import `bun:sqlite`, which node's ESM loader
-refuses before any module code runs, so only `./plan` and `./ports` load
-under node at all. `module` points at `./dist/index.js`, the same build
-the root of `exports` names. The package ships no type declarations:
+refuses before any module code runs, so only `./plan`, `./ports` and
+`./learning` load under node at all. `module` points at
+`./dist/index.js`, the same build the root of `exports` names. The package ships no type declarations:
 `exports` names no `types`, and a TypeScript consumer gets TS7016 under
 `strict`.
 
@@ -411,7 +411,7 @@ and a line here is ticked by the change that finishes the feature.
 - ✅ The right skills reach the right task, chosen when the plan is
   written
 - ⬜ Know which skills earn their place and which are ignored
-- ⬜ rafa learns from its own runs: what one task works out is handed
+- ✅ rafa learns from its own runs: what one task works out is handed
   to the tasks that need it later
 - ⬜ Skills and lessons shared across projects and machines
 - ⬜ Config as code: a typed `rafa.config.ts` holding your settings, your
@@ -465,12 +465,15 @@ rafa stands on other people's work and on earlier work of ours.
   evidence, scope) is adapted from the `continuous-learning-v2` skill of
   [`affaan-m/everything-claude-code`](https://github.com/affaan-m/everything-claude-code)
   by Affaan Mustafa (MIT).
-- **Shared learning (coming).** The design for merging what separate
-  runs learn (one record per lesson, a rule for conflicting lessons,
-  promotion on recurrence) follows Open Tomato's hive-learning design.
-  In rafa it is partly built: lessons are recorded per project today, and
-  sharing them across runs, projects and machines is on the
-  [Roadmap](#roadmap) and not available yet.
+- **Shared learning.** The design for merging what separate runs learn
+  (one record per lesson, a rule for conflicting lessons, promotion on
+  recurrence) follows Open Tomato's hive-learning design. rafa now records
+  lessons in `.rafa/instincts/` — one lesson per task finding that carries
+  a resolution — and pushes them after each task's report. Lessons that
+  meet a confidence floor are blessed and handed to tasks that need them
+  later; lessons that recur enough are promoted into the pages that own
+  their subjects. Sharing lessons across projects and machines is planned
+  for a future version.
 
 ## License
 

package/dist/PROMPT.md

@@ -2,7 +2,7 @@ We shared as much of the plan as this run is configured to share — the whole p
 
 Do not stage or commit anything: the loop owns staging and committing, and once this session exits cleanly it runs `git add -A` and commits your work under a subject derived from the task text. Leave your changes in the working tree, and leave them in a state the pre-commit hooks accept — a refused hook blocks the task and stops the loop.
 
-End your final message with exactly one `rafa:report` block shaped like the example below, and write nothing after it: the loop stores what it reads there, and a message without the block stores none of your findings. Write all seven fields, `status`, `feedback`, `findings`, `skills_used`, `blockers`, `out_of_scope_bugs` and `changes`, and write a list with nothing in it as `[]` rather than leaving its field out. `status` is `done` or `blocked`. `feedback` says what was done and how it went. `findings` is a list with one entry per distinct observation, never several merged into one; a finding's `kind` is one of `gotcha`, `pattern`, `location` or `skill-suggestion`, its `signal` is `loud` when it surfaced as a failure or `silent` when something passed while wrong, and its `artifact`, when there is one, is the exact string a recurrence would match on, such as an error message. `skills_used` names each skill you invoked. `blockers` lists what stopped the task, each entry a `what` and, when there is one, an `artifact`, `out_of_scope_bugs` the bugs you saw outside it, each bug with `security` set to `true` or `false`, and `changes` is the changelog for your diff, each entry holding the required fields `level` (one of patch, minor, major, none) and `summary` (a quoted line the user would understand), plus optional `area` (the changelog section). Write those closed-set words and `security` bare, as the example does, and double-quote every other value on one line: an unquoted value that opens with a backtick, `@`, `%` or `[` makes the whole block unreadable, and a `#` after a space silently cuts a value short.
+End your final message with exactly one `rafa:report` block shaped like the example below, and write nothing after it: the loop stores what it reads there, and a message without the block stores none of your findings. Write all seven fields, `status`, `feedback`, `findings`, `skills_used`, `blockers`, `out_of_scope_bugs` and `changes`, and write a list with nothing in it as `[]` rather than leaving its field out. `status` is `done` or `blocked`. `feedback` says what was done and how it went. `findings` is a list with one entry per distinct observation, never several merged into one; a finding's `kind` is one of `gotcha`, `pattern`, `location` or `skill-suggestion`, its `signal` is `loud` when it surfaced as a failure or `silent` when something passed while wrong, and its `artifact`, when there is one, is the exact string a recurrence would match on, such as an error message. A finding may also carry a `domain`, the area of work its lesson belongs to, one of `code-style`, `testing`, `git`, `debugging`, `workflow`, `security` or `general-best-practices`; leave it out when none fits. `skills_used` names each skill you invoked. `blockers` lists what stopped the task, each entry a `what` and, when there is one, an `artifact`, `out_of_scope_bugs` the bugs you saw outside it, each bug with `security` set to `true` or `false`, and `changes` is the changelog for your diff, each entry holding the required fields `level` (one of patch, minor, major, none) and `summary` (a quoted line the user would understand), plus optional `area` (the changelog section). Write those closed-set words and `security` bare, as the example does, and double-quote every other value on one line: an unquoted value that opens with a backtick, `@`, `%` or `[` makes the whole block unreadable, and a `#` after a space silently cuts a value short.
 
 ```rafa:report
 status: done
@@ -16,6 +16,7 @@ findings:
     resolution: "run bun install before the first test"
     artifact: "Cannot find package"
     signal: loud
+    domain: testing
 skills_used: ["git-workflow"]
 blockers: []
 out_of_scope_bugs:

package/dist/bundled/skills/dev-planner/SKILL.md

@@ -223,6 +223,7 @@ findings:
     resolution: "wrap append in try/finally"
     artifact: "EMFILE: too many open files"
     signal: loud
+    domain: debugging
   - trigger: "SQLite schema migration timing"
     kind: pattern
     what: "migrations run on every store init, not just schema changes"
@@ -262,6 +263,7 @@ Finding entry fields:
 | `resolution` | string | no | How to fix or work around it |
 | `artifact` | string | no | Error message, file path, or code snippet that signals the finding |
 | `signal` | string | yes | `loud` (it surfaced as a failure) or `silent` (it passed while wrong) |
+| `domain` | string | no | The area of work the finding's lesson belongs to: `code-style`, `testing`, `git`, `debugging`, `workflow`, `security` or `general-best-practices`. A value outside the set is reported as an issue and read as absent |
 
 Change note entry fields: