Repository navigation
Lessons: the agents' own are the supervisor's to keep; only one that changes what the owner set reaches the Inbox, in plain words - #222
Merged
Conversation
… one sent to the owner (--for-owner, with a plain line) reaches their Inbox Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…t too); preferences and withdrawn lessons go to the owner; review fixes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…Inbox A set line clearing for_owner on a lesson sent to the owner is ignored, like a rewording or an accept: otherwise the supervisor could unsend it, then keep it itself. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Member
Author
|
Reviewed at d0859e1:
CI passes 9 of 9. Merging. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
process/supervisor.md§4,governance/constitution.md,process/operator.md): a lesson about how the agents work is the supervisor's to accept itself once it cites plain evidence. That covers using the kit, the process, the tools, the workers' habits and the box. Only a lesson that would change something the owner set goes to the owner: the product's direction, a goal, a rule they gave, or an owner-only class. It is sent with a plain line that says what would change and why the owner should care. The owner can still retire any lesson.--kitlessons are also the operator's to harvest upstream. Accepting a lesson grants nothing.knowledge add|set … --for-owner --plain "<words>"(schema:knowledge.for_owner(const true) andknowledge.plain, both supervisor-only).hello), the tab title and the Loop count now include onlyfor_ownercandidates.orient, along with the commands to accept, retire or send them.--plainis refused if it contains backticks,--flags, kit words (devteam.mjsetc.), kit ids, file names, or hyphenated command, class or ticket names. It reuses ask'sKIT_WORDS,KIT_IDandUNSAFE_TEXTand theCOMMANDStable.preferencethe supervisor inferred, must be--for-owner.integrity()and in the fold, so a hand-written line counts for nothing.Why
The owner asked: "why are the Lessons open in stacks so jargonny?" Stacks had three candidate lessons in the owner's Inbox, written for agents, e.g. "check-pr reads tickets from main's log: after ticket add or ticket set (touches, done-whens), run log-sync and merge --chore log before the ticket's PR is checked…". These are operating lessons for the agents, backed by incidents. The owner can't judge them and shouldn't have to; the owner has said repeatedly that over-asking is unacceptable. After this lands, Stacks' three open candidates move to the supervisor's
orientlist. They stay visible to the owner, read-only, under the folded Loop section.Authority check:
authorise()accepts--approved k-…only for knowledge the owner created (writerClass(created_by) === 'owner'), accepted, scopedclass:<c>, and never for an owner-only class outsideowner_rules.decide --ononly records lineage. Trust promotion reads answered questions only. So a lesson the supervisor accepted approves nothing; a new test assertsdecide --class <owner_only> --approved <supervisor-accepted k>is refused.Tested
Node 24 locally:
test/ooda-knowledge.test.mjs,test/kit.test.mjs(82 pass),test/dashboard.test.mjs(144 pass), plus kit-lessons, plain-questions, machine, ooda-learning, ooda-lineage, ooda-signals, log-tolerance, search, bounds, approvals (60 pass).ooda-knowledge:orient; the supervisor accepts it.--for-ownerlesson reaches the owner with its plain line.--for-ownerwithout--plainis refused.devteam.mjs,check-pr, a kit id or a file are refused; "Node.js" and "sign-up" pass.--for-owner.test/lib/chain.mjs: the hub badge count now covers only lessons sent to the owner.test/next-step.test.mjs: the Inbox-order test's lesson is sent to the owner, since only such lessons are in the Inbox now. The first CI run caught this; next-step, links and recovery pass locally.Fable's adversarial review
Fixed:
status. Now refused in the CLI and ignored in the fold.chain.mjs's hub badge test still counted every candidate. Updated it, with a mix of sent and agent candidates..js/.tsbranch now matches only lowercase names.integrity()and the fold.preferenceself-accepted contradicted operator.md. It must now be--for-owner.Left as is (low priority, the refusal message explains itself): plain-check false positives on the hyphenated class name
new-feature,--used as a dash, and "rung".Fable found that the authority paths, the counts that must agree (hub, Inbox, title, gateway push) and the doc consistency were sound.
🤖 Generated with Claude Code