Trials P-24 and P-28 for an App's push; then the canary's token is revoked #27

Activity

1. don-petry

   added a parent issue on Oct 11, 2026

   • Epic: slice 0, foundations. The repo holds the line, its context is tested, and the platform facts are recorded #3
2. don-petry commented on Oct 18, 2026

   

   don-petry

   on Oct 18, 2026

   ContributorAuthor

   More actions

   Additions to P-28's App case, from #163's working rulings ("Design: where the last pusher and the base are read from").

   #163 rules that the last pusher is read from the newest activity entry for the head branch, and only when that entry's after is the head. P-28 so far shows that only for a person pushing through git. When this story runs, also record:

   • An App's push through git, with an installation token. Does an entry appear naming the App, with type: Bot?
   • An App moving the head through the API (PATCH /repos/{repo}/git/refs/...). This is how a Role may push. Does it appear in the activity, and how?
   • How far back the activity list goes. Until this is known, a pull request whose last push is older than the oldest kept entry reads null and waits for the Maintainer.
   • The least permission the reader App needs for the activity read, as Three Apps registered and installed, and their real grants compared with the data #26's amendment records for the queue.

   Until this runs, the fake GitHub's the_pusher_is_the_last_pusher is grounded only for a person's push.
3. don-petry commented on Oct 19, 2026

   

   don-petry

   on Oct 19, 2026

   ContributorAuthor

   More actions

   The sitting (plan review, 2026-10-19; the Maintainer chose this in chat, 2026-10-19)

   The machine user's token was set 2026-10-17 23:56Z for at most seven days, so the window ends by 2026-10-24. This story and #27 run in one sitting by the runbook runbook-p1-p7-p24.md (steps M1 to M10). The sitting is asked for by 2026-10-20, so that a "no" on P-1 or P-7, which would open a design issue on slice 1's approval mechanics, can be run again inside the window.

   Three additions to the runbook, none costing a click:

   1. P-38, observed. After M5 (the App pushes last), the READ already expects the Maintainer-approved review DISMISSED. From that same read, record whether the review is still readable with the commit it approved and its reviewer, and who the timeline names as dismissing it. That is P-38's question (design §6; decision 0025). If both hold, a_contract_approval_stays_on_its_commit is grounded by P-7.json and P-38 needs no run of its own in batch 2.
   2. The fake's rule an_approval_survives_a_push. The runbook already predicts it is wrong under this ruleset. The fixtures' PR corrects the rule's text in sim/grounding.py (an approval is dismissed as stale on a push under "dismiss stale approvals"), and sim/world.py if the world relies on it, rather than leaving it unverified.
   3. Code scanning fails on a security alert of any severity #95 in the same sitting. The Maintainer changes the repo's code-scanning failure threshold to any severity while he is at the settings; a session reads it back for The Factory repo's rulesets hold the Release tags and each required check's App #62's fixture.

   The runbook's step 8 (revoke the token, delete the secret, record on #27) closes the window; batch 2's trials that need the machine user (P-2, P-5, P-25) get a second token when their story runs.
4. don-petry commented on Oct 19, 2026

   

   don-petry

   on Oct 19, 2026

   ContributorAuthor

   More actions

   The machine user's canary access ended 2026-10-19 (the sitting for #14 and #27, by the runbook on #24).

   • P-24 passed (canary PR 35: the machine user's approval was the only review, and the pull request stayed REVIEW_REQUIRED and BLOCKED under /p24/ @don-petry; closed unmerged, branch deleted).
   • P-28 passed for an App's push (canary PR 34: the activity entry whose after is the head 355cb4d names combsmith-sf-trial-author[bot], type Bot).
   • The canary's copy of the token, the one secret of the main-only environment that machine-user-approves.yml read, was deleted on 2026-10-19 at about 20:40Z through the Maintainer's login; the environment now holds 0 secrets. The canary has no open pull request and no branch but main. The token itself the Maintainer keeps for its other uses, so it is not revoked at GitHub; the Maintainer judged the deletion of the canary's copy to meet this story's last condition.

   The fixtures (P-1, P-7, P-7.maintainer-pushed, P-24, P-28.app) and the grounding changes follow in one pull request. Also found on PR 34, for #14: the App's push dismissed the earlier approval (an_approval_survives_a_push is wrong under the ruleset), and the dismissed review keeps its commit with the pusher as the dismissal's actor (P-38).
5. don-petry

   closed this as completedin #212on Oct 20, 2026