row 287 (#1792): BUILD.md records sage-2916: 287 owns business.mjs :283-291 and its business.test.mjs cases (files-owned extension), the refusal rewritten to creative or chief with a gitea credential, B-1 to B-4 and M5, the old-message grep before in-review, PRD 1.15 REQ-LIB-6 check; Q1-Q4 accepted as assumptions; doc only

agents/megavolt/work/queue-287/BUILD.md

@@ -25,15 +25,26 @@ fixture admin and seat tokens finds nothing.
 - `packages/bus/tests/gitea-grant-docker.test.mjs`: the scratch gitea/gitea:1.27.1 container; it uses
   `os.tmpdir()`.
 
-## 1. Blockers and questions for Sage (and Dewey)
+## 1. Rulings, blockers and questions
 
 - B1, the publish rule. `business.mjs:286` refuses any `publish` entry that names a library project
   ("library repositories cannot be published by agents"). The brief's chief needs `publish: ["books"]`, and a
-  creative seat needs the library project in `publish` for `#giteaRole` and `#giteaTargets` to pass. The file
-  isn't in C2-21's files owned, and C2-08b's brief doesn't list it either. Proposal: C2-21 takes
-  `business.mjs` :283-291 (no test under packages/*/tests or scripts pins the :286 message), and turns the refusal into "a
-  library project in publish is allowed; the grant path gives it collaborator reach, never a fork". If row
-  285 already changes it, I build on that. Sage rules who owns it.
+  creative seat needs the library project in `publish` for `#giteaRole` and `#giteaTargets` to pass. No test
+  under packages/*/tests or scripts pins the :286 message (positive control: "publish names" hits
+  agent-identity.test.mjs).
+- Ruling sage-2916 (18:42Z 10-22), files-owned extension: row 287 owns `packages/business/src/business.mjs`
+  :283-291 and the `packages/business/tests/business.test.mjs` cases for it. Row 285 leaves business.mjs
+  alone. Conditions:
+  - The refusal is rewritten, not deleted. A library project in `publish` loads only for a creative
+    instance (`CREATIVE_DEFINITIONS`) or the chief of staff, each with a gitea credential. Any other
+    instance still refuses, with a new message that names the rule. Tests cover both sides. The grant path
+    serves an allowed one with collaborator reach, never a fork. (To confirm on the base: how business.mjs
+    names the chief, by definition `chief-of-staff` or by `launch.by`.)
+  - Before in-review, grep 'packages/*/tests/*' and `scripts/test-*.sh` again for the old message text,
+    with a positive control.
+  - PRD 1.15 REQ-LIB-6 is the authority for this. If Mos changes 1.15 (sage-2914, `library.write`
+    routing), check this text against what lands.
+- Q1 to Q4 below: Sage accepted them as stated assumptions (sage-2916). Dewey checks them in the round.
 - Q1, the hash. `identitySha256` covers identity, publish and remotes, not a project's kind or the role's
   definition name, and the level comes from the definition name. Proposal: add a `library` key
   (`{project: level}`) to the hash input only when a publish project is a library, so every non-library
@@ -42,9 +53,10 @@ fixture admin and seat tokens finds nothing.
   Proposal: `forks` stays (empty when every target is a library), and a `repositories:
   [{project, repository, level}]` key appears only when a library target exists. The notice names them the
   same way.
-- Q3, mixed raises. A creative raise must name only library projects (mos-1320 item 2). A non-creative
-  role (the chief, or a coder) may name a library project next to forked ones in one raise; step 4 forks the
-  others and adds the collaborator on the library one. Proposal: allow that, and test it.
+- Q3, mixed raises. A creative raise must name only library projects (mos-1320 item 2). The chief may
+  name a library project next to forked ones in one raise; step 4 forks the others and adds the collaborator
+  on the library one. Proposal: allow that, and test it. Under sage-2916, any other non-creative instance
+  can't hold a library project in `publish` at all, so the business file refuses it before any raise.
 - Q4, the token search for the Docker test. The fake API's tokens are fixtures and can be grepped. The
   Docker test's tokens are minted by the container at run time, so the gate grep can't know them in advance.
   Proposal: the Docker test captures its own diagnostics and asserts that no token it minted appears in
@@ -94,8 +106,8 @@ Docker (`gitea-grant-docker.test.mjs`), each fact first, before any code is trus
 
 Fake API (`gitea-grant.test.mjs`, `fake-gitea-api.mjs`): collaborators carry a permission, `repoJson`
 returns `permissions`, and the PUT route requires a site admin token with `write:repository`.
-- L1 a creative definition gets `write`; L2 the chief gets `read`; L3 a non-creative, non-chief role gets
-  `read`.
+- L1 a creative definition gets `write`; L2 the chief gets `read`, including a mixed raise of the library
+  project and a forked one (Q3).
 - L4 a repository with `push: true` for a read grant, or `admin: true`, refuses `gitea-reach-wider` naming it.
 - L5 revoke deletes the token and leaves the collaborator.
 - L6 a non-library project still forks, and its `grant.applied` body is byte-identical to today's.
@@ -105,6 +117,12 @@ returns `permissions`, and the PUT route requires a site admin token with `write
 - L9 the chief raises its own grant through `credential.mint`.
 - Install test: the business file gives the chief `identity` and `publish`.
 
+Business (`business.test.mjs`, sage-2916): B-1 a creative instance with identity, a gitea credential and a
+library project in `publish` loads; B-2 so does the chief; B-3 any other instance with a library project in
+`publish` refuses with the new message; B-4 a creative instance or the chief without a gitea credential
+still refuses under the existing `publish needs identity and a gitea definition` rule. Mutant: M5 drop the
+creative-or-chief condition (any instance loads), killed by B-3.
+
 Mutants: M1 drop the library-only condition from `#giteaRole` (the brief's), killed by L7. Others to list
 once the code exists: the level forced to `write` (L2), step 5's exact-permission check loosened to
 `push || pull` (L4), the fork path taken for a library project (L1, a fork call counted).