[hhff]

What

• governance/constitution.md: owner_rules: ["gate-change"], the owner-only classes the owner may settle with their own standing rule. The prose says the rule is given from the dashboard or the owner's terminal, never relayed from chat.
• scripts/devteam.mjs:
  • merge: when every changed owner setting is of a class in owner_rules and the owner has an accepted rule scoped class:<cls>, the merge is approved by the rule and says so, with no --approved. A PR that also changes any other owner class still needs an answer.
  • decide/act --approved <k-rule> accept such a rule.
  • decisionAuthorityGap lets a standing-rule decision in such a class reach the rule check.
  • New ownerRuleFor(cls).
• test/kit.test.mjs:
  • a rule relayed from chat is refused;
  • the owner's rule approves a gates-only chore;
  • the same chore with upstream_repo (governance-edit) added still needs an answer.

Why

The owner told stacksbot that new dev tools can be added without asking ("I've already told you new dev tools can be added without asking me. Do it autonomously going forward"). The kit couldn't honor that, so the supervisor kept asking. Asked here, the owner chose that their standing rule may cover any gate-change, removing and loosening gates included. They were told it would let the supervisor weaken the checks that review its own work.

Authority

• This is a deliberate widening, decided by the owner.
• It is bounded to classes listed in owner_rules (only gate-change), to rules the owner wrote themselves (answer --from-chat refuses --rule, and the rule's writer must be the owner), and to accepted rules with exactly class:gate-change scope.
• It never covers another owner class in the same PR.

Migration

None required. To use it, the owner answers a gate-change question with "Keep this answer as a standing rule" (scope class:gate-change), or runs answer <qid> yes --rule "…" --rule-scope class:gate-change. An existing rule with project scope doesn't count; it must be scoped to the class.

🤖 Generated with Claude Code

[hhff]

Merging for v0.20.1 (upstream loop).

• Local release candidate (main with Tests never reach the machine's default tmux server #117, plus An owner's answer binds to the question as the owner saw it #116, Tickets in other repos: one fleet, one log and one graph across sibling repos #108, Lessons: keep one with an owner's note that refines it #114 and gate-change can be settled by the owner's own standing rule #115): Node 24.14.1 passed 122/123. The one failure is the hub test's "both instances listed with counts" timeout under load; it passed in the previous candidate's run and on CI.
• CI: 18/20/22/24 green on this head, with main merged in.
• Next: main's own CI checks the combined result before the tag.