Skip to content

Trials P-27, P-14, P-4, P-9 and P-20: forks, caches, narrowed tokens, chaining and the public nudge #187

Closed

Description

@don-petry

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.

Design. §6, P-27, P-14, P-4, P-9, P-20; §6.1 batch 2; §7.3.

Activity

  1. don-petry commented on Oct 20, 2026

    @don-petry
    ContributorAuthor

    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.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).

  2. don-petry commented on Oct 20, 2026

    @don-petry
    ContributorAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions