You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Trials P-27, P-14, P-4, P-9 and P-20: forks, caches, narrowed tokens, chaining and the public nudge #187
Part of the epic "Epic: slice 1, first approval. A Release on next reviews a pull request to this repo, and the machine user's approval stands".
Why. Batch 2 of §6.1. None of these needs the machine user, so they run as soon as #27 has revoked its token, in the trial lane, while slice 0 finishes.
Done when
P-27: a fork's pull-request workflow run waits for approval, and can never be a schedule or dispatch run.
P-14: a job with no permissions and no cache action cannot write the default-branch cache scope.
P-4: an installation token minted with a subset of the App's permissions and repos works, and is refused beyond them.
P-9: a pass can start the next one with the default workflow token (actions: write on that job alone).
P-20: an event anyone may cause (starring a designated repo) starts a workflow, often enough for a tick every minute or two; how often is recorded.
Each fixture grounds its rule in sim/grounding.py, or the design's §7.3 is amended by pull request where the answer is no.
Order. P-20 first of the five: W-2 rests on the relay alone, since the schedule is a backstop of hours ("Design: a scheduled tick is a backstop of hours, not minutes (P-8 ticks failed)", #246), and P-20 settles the public event the relay nudges through. P-31, the relay's host, is a story of its own (#254). The other four in any order.
Needs. How a trial is run. The trial-author App (still installed until batch 2 ends, #24 write 7) for the fork and token cases; the Maintainer at his terminal for anything that mints a token.
Solution Architect, delegated. On main at 31800f6 (#221). Read from the issue, design §6 (P-27, P-14, P-4, P-9, P-20), §6.1 batch 2, §7.3 (noticing work, the relay and the public nudge), §4.9 (credentials), sim/grounding.py, .claude/skills/run-a-platform-trial/SKILL.md, the plan review's batch 2c note, and #163's ruling on a fork's head (no outside account exists). #27 is closed and the machine-user token revoked; none of these needs it.
What this story decides. Five trials of batch 2 that need no machine user, each one question with its pass condition from §6, and what each grounds. They can run now, in the trial lane, beside every other lane.
1. Who acts. The Maintainer's own login on the canary for P-9, P-14, P-20 and P-27's second half, through workflows in the canary that are pinned, least-privileged and hold no logic, as the standard asks of ours, and whose captures are masked and redacted inside the job. P-4 mints a token, so it runs at the Maintainer's own terminal with the trial-author App's key, as tools/trial_as_app.sh runs, and only the redacted answers come here. P-27's first half needs a fork by an account without write access: see "Needs the Maintainer".
2. P-27, a fork's run. Two halves. (a) Waits for approval: a pull request from a fork by an account that has not contributed; its workflow run shows action_required until a person approves it. (b) Never a schedule or dispatch run: a fork's workflow file does not run on schedule or workflow_dispatch in the base repo; the run record of the fork's pull-request run carries event: pull_request, head_repository.fork: true and the fork's head_branch. Half (b) runs with the Maintainer's own fork of the canary, whose runs need no approval: the record's shape is the same. Half (a) waits for an outside account. The Kernel already counts no such run: I-34 counts a run of the Factory's own workflow file, on the default branch, started by a schedule or a dispatch; the fixture is what grounds that reading, a_forks_run_never_counts below, and (a) bounds only the cost of a stranger's push.
3. P-14, the cache. A workflow in the canary with permissions: {} and no cache action tries to write the default-branch cache scope through the cache API with its default token, and the answer is 403, or the write lands and the design's §4.9 assumption falls. The pass is "cannot".
4. P-4, a narrowed installation token. At the Maintainer's terminal: an installation token for the trial-author App minted with a subset of its permissions and one repository, used for a read it permits (200) and a write it does not (403), and on a repository it does not name (404). The fixture keeps the requests and the status codes, and the redaction deletes every token. The pass is "yes".
5. P-9, chaining. A workflow in the canary whose one job holds actions: write dispatches the same workflow once, with an input that stops the chain at two, and the second run's record names workflow_dispatch and the first run's actor. The pass is "yes". It also records whether the dispatch's 204 is followed by the run within P-17's window, since the successor pass is what §7.3 chains on.
6. P-20, the public nudge. A workflow on watch in the canary; the Maintainer's account stars and unstars it ten times over ten minutes, and the fixture records each run's created_at against each star's time, and how many stars started no run. The pass is "yes, often enough for a tick every minute or two"; the measured rate is what §7.3's relay rests on. Which host carries the relay is P-31, not this.
7. Grounding.sim/grounding.py gains, appended, each with its trial and its fixture once it passes: a_forks_run_never_counts ("A pull request from a fork runs its own workflow file, on pull_request, never on a schedule or a dispatch, and I-34 counts none of it", P-27); a_pass_starts_its_successor ("A pass can dispatch the next with its own job's token", P-9); a_public_event_starts_a_pass ("An event anyone may cause starts the poller's workflow, within a minute or two", P-20). P-14 and P-4 ground no rule of the fake, which models no cache and no token: their fixtures hold §4.9's two assumptions, and §4.9 gains "(P-14, trials/P-14.json)" and "(P-4, trials/P-4.json)" where it states them. Where an answer is "no", §7.3 or §4.9 is amended by pull request, as the issue says, and the rule stays unverified.
8. Record and design. No new decision. §6's five rows gain their pass or fallback with the fixture's name; §4.9 and §7.3 gain the fixture references; the simulator's rules as in ruling 7.
9. Files, and shared files. New: five fixtures, trials/P-27.json, P-14.json, P-4.json, P-9.json, P-20.json, named as the skill names them, with a second file where a trial leaves two. Edited: sim/grounding.py (append), the design's §6, §4.9, §7.3. The workflows live in the canary and are removed after (step 8 of the skill), except where a trial's verdict says to keep watching. Shared: sim/grounding.py with lanes a and b, append only.
10. Gates.python3 -m tools.check_trials before any git add; export verify; a fresh Claude review and a security pass against the credential rules (no token, no --show-token, nothing minted here, every capture redacted); Muse; no AGY. One PR for the five, or one for each if the outside account delays P-27; each says "Part of #187" or "Closes #187", the verdicts, what was removed and what was undone in the canary.
11. Out of scope. P-31 (the relay's host); P-2, P-5, P-23, P-25 (batch 2a) and P-35 to P-38 (batch 2b), each its own story; P-26 (the CLI's sandbox); the poller's own workflow, which chains as P-9 shows once controller/ exists.
Needs the Maintainer? One point, on identity: P-27's first half needs a fork by an account without write access, which no trial has had (#163's ruling took null for a fork's head for the same reason). Options: (1) the Maintainer creates one outside account for the trials and keeps it, which also lets #163's fork case and P-34's outsider reopening run; (2) P-27 ships with its second half only and the first waits, the fixture saying so; (3) a colleague's account forks once. Recommend (2) now, and (1) when the Maintainer wants the three outside cases closed at once; nothing in slice 1 waits on (a).
Maintainer's answer on the ruling's open point (2026-10-20, in chat to the orchestration session): he will provide a non-member GitHub account for P-27's approval-wait half, so P-27 runs whole in one sitting; the three outside-account cases are not deferred. The account's name comes from him before the sitting, never from a session.
Activity
don-petry commentedon Oct 20, 2026
Working rulings (overturnable in review)
Solution Architect, delegated. On main at 31800f6 (#221). Read from the issue, design §6 (P-27, P-14, P-4, P-9, P-20), §6.1 batch 2, §7.3 (noticing work, the relay and the public nudge), §4.9 (credentials),
sim/grounding.py,.claude/skills/run-a-platform-trial/SKILL.md, the plan review's batch 2c note, and #163's ruling on a fork's head (no outside account exists). #27 is closed and the machine-user token revoked; none of these needs it.What this story decides. Five trials of batch 2 that need no machine user, each one question with its pass condition from §6, and what each grounds. They can run now, in the trial lane, beside every other lane.
1. Who acts. The Maintainer's own login on the canary for P-9, P-14, P-20 and P-27's second half, through workflows in the canary that are pinned, least-privileged and hold no logic, as the standard asks of ours, and whose captures are masked and redacted inside the job. P-4 mints a token, so it runs at the Maintainer's own terminal with the trial-author App's key, as
tools/trial_as_app.shruns, and only the redacted answers come here. P-27's first half needs a fork by an account without write access: see "Needs the Maintainer".2. P-27, a fork's run. Two halves. (a) Waits for approval: a pull request from a fork by an account that has not contributed; its workflow run shows
action_requireduntil a person approves it. (b) Never a schedule or dispatch run: a fork's workflow file does not run onscheduleorworkflow_dispatchin the base repo; the run record of the fork's pull-request run carriesevent: pull_request,head_repository.fork: trueand the fork'shead_branch. Half (b) runs with the Maintainer's own fork of the canary, whose runs need no approval: the record's shape is the same. Half (a) waits for an outside account. The Kernel already counts no such run: I-34 counts a run of the Factory's own workflow file, on the default branch, started by a schedule or a dispatch; the fixture is what grounds that reading,a_forks_run_never_countsbelow, and (a) bounds only the cost of a stranger's push.3. P-14, the cache. A workflow in the canary with
permissions: {}and no cache action tries to write the default-branch cache scope through the cache API with its default token, and the answer is 403, or the write lands and the design's §4.9 assumption falls. The pass is "cannot".4. P-4, a narrowed installation token. At the Maintainer's terminal: an installation token for the trial-author App minted with a subset of its permissions and one repository, used for a read it permits (200) and a write it does not (403), and on a repository it does not name (404). The fixture keeps the requests and the status codes, and the redaction deletes every token. The pass is "yes".
5. P-9, chaining. A workflow in the canary whose one job holds
actions: writedispatches the same workflow once, with an input that stops the chain at two, and the second run's record namesworkflow_dispatchand the first run's actor. The pass is "yes". It also records whether the dispatch's 204 is followed by the run within P-17's window, since the successor pass is what §7.3 chains on.6. P-20, the public nudge. A workflow on
watchin the canary; the Maintainer's account stars and unstars it ten times over ten minutes, and the fixture records each run'screated_atagainst each star's time, and how many stars started no run. The pass is "yes, often enough for a tick every minute or two"; the measured rate is what §7.3's relay rests on. Which host carries the relay is P-31, not this.7. Grounding.
sim/grounding.pygains, appended, each with its trial and its fixture once it passes:a_forks_run_never_counts("A pull request from a fork runs its own workflow file, onpull_request, never on a schedule or a dispatch, and I-34 counts none of it", P-27);a_pass_starts_its_successor("A pass can dispatch the next with its own job's token", P-9);a_public_event_starts_a_pass("An event anyone may cause starts the poller's workflow, within a minute or two", P-20). P-14 and P-4 ground no rule of the fake, which models no cache and no token: their fixtures hold §4.9's two assumptions, and §4.9 gains "(P-14,trials/P-14.json)" and "(P-4,trials/P-4.json)" where it states them. Where an answer is "no", §7.3 or §4.9 is amended by pull request, as the issue says, and the rule stays unverified.8. Record and design. No new decision. §6's five rows gain their pass or fallback with the fixture's name; §4.9 and §7.3 gain the fixture references; the simulator's rules as in ruling 7.
9. Files, and shared files. New: five fixtures,
trials/P-27.json,P-14.json,P-4.json,P-9.json,P-20.json, named as the skill names them, with a second file where a trial leaves two. Edited:sim/grounding.py(append), the design's §6, §4.9, §7.3. The workflows live in the canary and are removed after (step 8 of the skill), except where a trial's verdict says to keep watching. Shared:sim/grounding.pywith lanes a and b, append only.10. Gates.
python3 -m tools.check_trialsbefore anygit add; export verify; a fresh Claude review and a security pass against the credential rules (no token, no--show-token, nothing minted here, every capture redacted); Muse; no AGY. One PR for the five, or one for each if the outside account delays P-27; each says "Part of #187" or "Closes #187", the verdicts, what was removed and what was undone in the canary.11. Out of scope. P-31 (the relay's host); P-2, P-5, P-23, P-25 (batch 2a) and P-35 to P-38 (batch 2b), each its own story; P-26 (the CLI's sandbox); the poller's own workflow, which chains as P-9 shows once
controller/exists.Needs the Maintainer? One point, on identity: P-27's first half needs a fork by an account without write access, which no trial has had (#163's ruling took
nullfor a fork's head for the same reason). Options: (1) the Maintainer creates one outside account for the trials and keeps it, which also lets #163's fork case and P-34's outsider reopening run; (2) P-27 ships with its second half only and the first waits, the fixture saying so; (3) a colleague's account forks once. Recommend (2) now, and (1) when the Maintainer wants the three outside cases closed at once; nothing in slice 1 waits on (a).don-petry commentedon Oct 20, 2026
Maintainer's answer on the ruling's open point (2026-10-20, in chat to the orchestration session): he will provide a non-member GitHub account for P-27's approval-wait half, so P-27 runs whole in one sitting; the three outside-account cases are not deferred. The account's name comes from him before the sitting, never from a session.
Trial workflow p14-cache-scope (combsmith/software-factory#187)
Trial workflow p9-chain (combsmith/software-factory#187)
Trial workflow p27-pull-request (combsmith/software-factory#187)
Trial workflow p20-watch (combsmith/software-factory#187)
Trial workflow p14-cache-scope (combsmith/software-factory#187)
Trial workflow p9-chain (combsmith/software-factory#187)
Trial workflows for P-27, P-14, P-9 and P-20 (combsmith/software-fact…
Remove trial workflow p27-pull-request (combsmith/software-factory#187,…
Remove trial workflow p20-watch (combsmith/software-factory#187, step 8)
Remove trial workflow p14-cache-scope (combsmith/software-factory#187,…
Remove trial workflow p9-chain (combsmith/software-factory#187, step 8)
Remove the batch 2c trial workflows (combsmith/software-factory#187, …
Trials P-27, P-14, P-9 and P-20 (pass) and P-4 (fail): forks wait, ca…
The fix round: verdicts by the ruling, the mint held in a variable, a…
Trials P-27, P-14 and P-20 (pass), P-4 and P-9 (fail): forks wait and…