diff --git a/docs/FORMAL_REQUIRED_CHECKS.md b/docs/FORMAL_REQUIRED_CHECKS.md index 06765589e..1cbe8611e 100644 --- a/docs/FORMAL_REQUIRED_CHECKS.md +++ b/docs/FORMAL_REQUIRED_CHECKS.md @@ -47,6 +47,12 @@ authenticate independent semantic review, or promote mathematical status. The pre-change main ruleset23798639 requires verify/public-intake/public-shop; Math-24045351 requires math-downstream-gates. Both require zero GitHub approving reviews. Main has a pre-existing repository-role PR bypass; Math- has none. +*Correction, 2026-10-07 (live read):* the sentence "Main has a pre-existing +repository-role PR bypass" is the 27 September snapshot, superseded. The bypass +actor on main ruleset 23798639 is the ChatGPT Codex Connector integration +(1144995), bypass mode `always`, exempt from every rule of that ruleset; see +[OP-ACCESS-20261007](../governance/OP-ACCESS-20261007.md), the access record; the +bypass disposition (remove, or record as an accepted exception) is pending. This code uses the already-required contexts and does not claim to edit settings. The managed connector does not expose ruleset writes. Do not bypass a rule or claim an administrator change without a successful write and independent readback. diff --git a/docs/PUBLIC_SHOP_SETUP.md b/docs/PUBLIC_SHOP_SETUP.md index 4c9707a67..6eb9638b2 100644 --- a/docs/PUBLIC_SHOP_SETUP.md +++ b/docs/PUBLIC_SHOP_SETUP.md @@ -26,7 +26,7 @@ The first five bounded tasks are [#141](https://github.com/d6g8k5htny-coder/main **Math- verified active:** [Proof vault: reviewed changes](https://github.com/d6g8k5htny-coder/Math-/rules/24045351) protects its default `main` branch. It requires a pull request, resolved conversations, and an up-to-date **math-downstream-gates** check from GitHub Actions. Force pushes and deletion are blocked; the bypass list is empty. -**Main verified active:** [Verified pull requests](https://github.com/d6g8k5htny-coder/main/rules/23798639) requires a pull request, resolved conversations, and up-to-date **verify**, **public-shop**, and **public-intake** checks from GitHub Actions. Force pushes and deletion are blocked. The existing repository-admin bypass is restricted to pull requests; it was not expanded. See the [installation receipt](https://github.com/d6g8k5htny-coder/main/pull/149#issuecomment-5848091891), recorded separately from the deployment PR. The external results guard is **public-intake**; its tests are a different check. A green replay is not mathematical acceptance. Do not grant outsiders direct write access. +**Main verified active:** [Verified pull requests](https://github.com/d6g8k5htny-coder/main/rules/23798639) requires a pull request, resolved conversations, and up-to-date **verify**, **public-shop**, and **public-intake** checks from GitHub Actions. Force pushes and deletion are blocked. The existing repository-admin bypass is restricted to pull requests; it was not expanded. See the [installation receipt](https://github.com/d6g8k5htny-coder/main/pull/149#issuecomment-5848091891), recorded separately from the deployment PR. *Correction, 2026-10-07 (live read):* the two sentences "Force pushes and deletion are blocked. The existing repository-admin bypass is restricted to pull requests; it was not expanded." are the 26 September snapshot and are superseded. The bypass list of that ruleset holds the ChatGPT Codex Connector integration (1144995) with bypass mode `always`, which exempts that one actor from every rule of the ruleset on `main`: the pull-request requirement, the three checks, the non-fast-forward rule and the deletion rule. For every other actor those rules, including the force-push and deletion blocks, stay in force. The ruleset was last updated 2026-09-28T06:22Z, after the receipt. See [OP-ACCESS-20261007](../governance/OP-ACCESS-20261007.md), where the disposition (remove, or record as an accepted exception) is pending. The external results guard is **public-intake**; its tests are a different check. A green replay is not mathematical acceptance. Do not grant outsiders direct write access. **Single-account autonomous operation (owner-directed correction, 2026-09-26):** both rulesets require **zero GitHub approving reviews**, and approval of the latest reviewable push is disabled. This removes the second-account dependency: authorized agents may review and merge eligible PRs without requesting routine permission from Dylan. Do not reinstate account-count approval gates as a substitute for agent review. Preserve nonauthor technical reviews as exact-source comments or artifacts, disclose authorship and provider, and give same-provider reviews zero organizational-independence credit. Required theorem-specific review predicates and unresolved scientific holds remain separate from engineering merge eligibility. Dismissal of stale optional approvals remains enabled; the Copilot extra-approval option applies only when a nonzero approval count is required. Neither repository has classic branch protection configured. This supersedes the approval-count/latest-push settings in the historical installation receipt; all other protections described above remain. diff --git a/governance/OP-ACCESS-20261007.md b/governance/OP-ACCESS-20261007.md new file mode 100644 index 000000000..00aa5ba05 --- /dev/null +++ b/governance/OP-ACCESS-20261007.md @@ -0,0 +1,272 @@ +# OP-ACCESS-20261007 — GitHub access for participating lanes + +Effective owner instruction, recorded 2026-10-07 by Anthropic Claude (the +dedicated project auditor, "Auditor-C1", Claude Code session `01UzNu9j…`) on +Dylan Roy's instruction, given directly in that session. Scientific effect NONE. +Nothing here changes a status, flag, premise, prize or register. + +## Exact owner instruction + +After the auditor reported that attaching repositories with write access had +been refused by its own session and that other lanes record the same kind of +refusal, Dylan wrote: + +> Approval for all. + +> Make this a one time primary target and get this resolved for any and all +> agents that enter the GitHub as every agent should have those permissions. +> Feel free to ask the other agents who have been there a while qualifying +> questions to get a better understanding. You have my full authority to make +> changes as after you figure out where the problems are. + +## What this record establishes + +1. **Standing authorization.** Every participating lane is authorized to read + and write in this account's project repositories within the + [current workflow](OP-WORKFLOW-20260930.md): comments, branches, pull + requests, reviews and integration. This restates the + [owner delegation](OP-AUTONOMY-20260923-v2.1.md) and the + [5 October decision](OWNER_DECISION_20261005_CURSOR.md); it adds nothing to + the scientific-effect boundary and removes no required check. A lane does + not ask Dylan to re-grant this. For the four project repositories, the only + owner actions that remain are the four listed below, and none of them is a + per-task approval. One account-level step outside them is already recorded + in [docs/PUBLIC_SHOP_SETUP.md](../docs/PUBLIC_SHOP_SETUP.md): including + the profile README repository `d6g8k5htny-coder/d6g8k5htny-coder` in the + connected app's repository access so that the prepared banner can be + delivered. That record stands unchanged; this session did not re-inspect + that repository. +2. **Where the refusals come from.** Between 1 and 7 October, lanes recorded + more than seventy GitHub write refusals on + [main#229](https://github.com/d6g8k5htny-coder/main/issues/229) and + [main#275](https://github.com/d6g8k5htny-coder/main/issues/275). The + refusals themselves are confirmed; their sources are candidates, read + together with the live repository settings. None of the recorded + refusals is a missing owner permission for the repositories, though a + missing permission grant on the Cursor installation is not excluded + (owner action 4). The candidate sources are: + - the token that Cursor mints for a Cloud Agent, reported by Cursor users + and staff to lack the `issues` scope; here, Cloud Agent writes were + observed to succeed only on the task repository (this project's token + was not inspected, and whether that task-only result comes from the + token's own scope or from an installation that held only that repository + is UNKNOWN, see owner action 4); + - the OpenAI and Claude harnesses or proxies, which refused + repository-settings writes in the recorded cases, and the Claude harness, + which refused repository attaches, credential reads and some writes in + the recorded cases: three Claude sessions with the same owner approval on + 7 October reported different attach outcomes, `query-` and + `Universal-Law-Workspace` refused (this record), nothing refused among + `main`, `query-` and `Math-` (one session, one day, no credential + inspection, + [229/6042010039](https://github.com/d6g8k5htny-coder/main/issues/229#issuecomment-6042010039)), + and `Math-` alone refused inside a batch whose other three attaches + succeeded + ([229/6042173762](https://github.com/d6g8k5htny-coder/main/issues/229#issuecomment-6042173762), + which reads its own result as per call; that reading is the reporter's). + The comparison establishes those outcomes; the cause, whether a refused + call would succeed if repeated, and what another runtime can do are not + established by it. Other lanes' settings access is not recorded; + - the rulesets, which require pull requests and the named checks on the + default branches. +3. **A ruleset asymmetry to decide.** The `main` ruleset lists one lane's + integration as a bypass actor; `Math-` has none. See "Rulesets". + +## Observed capability by lane (live reads, 2026-10-07 14:40–16:05Z) + +The GitHub principal depends on the authentication path, not only on the +app. User-to-server tokens post as the owner's user (`d6g8k5htny-coder`, with +the app named as `performed_via_github_app`); installation tokens post as the +app's bot. The OpenAI connector uses both: its cloud lanes post as the owner's +user, while its automated pull-request review posts as +`chatgpt-codex-connector[bot]` (for example on main#276). The Cursor Cloud +Agent installation posts as `cursor[bot]`. Which path the `main` ruleset's +bypass covers is not established from here; for the connector's own +user-to-server principal the ruleset answers `current_user_can_bypass: +never` on both repositories +([229/6042109593](https://github.com/d6g8k5htny-coder/main/issues/229#issuecomment-6042109593)), +which is the caller-specific answer and says nothing about the installation +path or about past use. "Yes" means observed in the record; +"no" means a refusal, or an operation the lane's tooling does not expose, +recorded in the cited comment; anything else is "not recorded". + +| Lane and identity | Issue comments | PR comments, reviews, merge | Push | Workflow dispatch or re-run | Repository settings | +|---|---|---|---|---|---| +| OpenAI — ChatGPT Codex Connector (app 1144995) | yes | yes | yes | not recorded | no: its connector exposes no settings mutation ([227/6003255968](https://github.com/d6g8k5htny-coder/main/issues/227#issuecomment-6003255968), [227/6005800925](https://github.com/d6g8k5htny-coder/main/issues/227#issuecomment-6005800925)) | +| Anthropic — Claude (app 1236702), on repositories attached to the session | yes | yes | yes | not recorded | no: `PATCH /repos/…` → 403 from its proxy ([227/6007892354](https://github.com/d6g8k5htny-coder/main/issues/227#issuecomment-6007892354)) | +| Cursor in user mode (app 1210556, posting as the owner's user) | yes | yes | yes | not recorded | not recorded | +| Cursor Cloud Agents (`cursor[bot]`, installation token) | **no**: 403 `Resource not accessible by integration`, accepted permission `issues=write` ([229/6005711215](https://github.com/d6g8k5htny-coder/main/issues/229#issuecomment-6005711215) and about sixty more) | comments on the task repository's pull requests: yes ([Math-#302 6004855848](https://github.com/d6g8k5htny-coder/Math-/pull/302#issuecomment-6004855848) and four more by `cursor[bot]`); merge: yes (Math-#302 and #304 were merged by `cursor[bot]`); reviews: not recorded | yes on the task repository; **no** across repositories ([229/6007072331](https://github.com/d6g8k5htny-coder/main/issues/229#issuecomment-6007072331)) | **no**: 403, accepted permission `actions=write` ([229/6005792380](https://github.com/d6g8k5htny-coder/main/issues/229#issuecomment-6005792380)) | not recorded | +| xAI — Grok (by xAI) (app 2875373) | yes | yes | not recorded | not recorded | not recorded | +| GitHub Actions (integration 15368) | — | status checks only | — | — | — | + +The recorded endpoints and statuses above are this project's own lane +evidence. The candidate explanation is a limitation Cursor users and staff +describe: in a Cursor forum thread, users report that the app's installation +page shows `Issues: Read and write` while the token minted for the sandbox +omits the `issues` scope, and Cursor staff describe that as a known +limitation and name a workaround, a `GH_TOKEN` secret in the Cloud Agent +settings +([forum thread, June–September 2026](https://forum.cursor.com/t/cloud-agent-gh-git-token-missing-issues-write-despite-github-app-being-granted-issues-read-write/163389)). +It is a hypothesis for this project, not a finding: this project's +installation page and the minted token were not inspected by the auditor +(owner-only), so a setting of this installation is not ruled out, and the +recorded `X-Accepted-GitHub-Permissions` values name the permission each +refused endpoint requires, not the permissions the token held, so they do not +distinguish the reported token limitation from an installation setting or +from another integration or proxy restriction. For this project the root +cause therefore stays reported, not confirmed; the refusals themselves are +confirmed. The installation's permissions page (owner action 4) can say only +whether that installation currently grants Issues write. If it does not, +record the missing permission as an identified configuration obstacle, +without treating it as proof of which layer produced a historical refusal. +If it does, that one explanation is absent at the inspected installation and +time; repository inclusion, the minted token's actual permissions and +integration or proxy restrictions still need their own evidence, such as one +issue comment attempted with the installation token and its recorded status. +A successful authenticated comment establishes that operation, not the cause +of earlier failures. +Whether that secret restores agent-driven writes is not established: the Codex +review of this record cites a 6 October staff reply that the secret +authenticates `gh` while the agent's instructions still treat it as read-only +for writes ([thread 173522](https://forum.cursor.com/t/cloud-agent-instructions-block-gh-writes-even-when-a-write-scoped-gh-token-is-provided/173522), +not opened by the auditor). The lanes' own workaround, recording the verdict by +editing the bot's acknowledgement comment and having another lane post board +records, is consistent with the cause and stays in force until a Cloud Agent's +new issue comment is observed to succeed; record the first such success here. +No lane reports a Cloud Agent run with the secret so far +([229/6042013379](https://github.com/d6g8k5htny-coder/main/issues/229#issuecomment-6042013379)). + +## Rulesets (live reads, 2026-10-07) + +| Repository | Ruleset | Rules | Bypass list | +|---|---|---|---| +| main | 23798639 "Verified pull requests", `main` and `codex/enforcement-probe-20260922` | deletion, non-fast-forward, creation, pull request (0 approvals, thread resolution, stale reviews dismissed), required checks `verify`, `public-intake`, `public-shop` (strict) | **ChatGPT Codex Connector integration (1144995), bypass mode `always`** | +| Math- | 24045351 "Proof vault: reviewed changes", default branch | the same rule set with required check `math-downstream-gates` (strict) | none | + +The bypass exempts one lane from the pull-request requirement, the three +required checks, non-fast-forward and deletion protection on `main`. +[docs/FORMAL_REQUIRED_CHECKS.md](../docs/FORMAL_REQUIRED_CHECKS.md) described it +as "a pre-existing repository-role PR bypass", and +[docs/PUBLIC_SHOP_SETUP.md](../docs/PUBLIC_SHOP_SETUP.md) and the +[installation receipt of 26 September](https://github.com/d6g8k5htny-coder/main/pull/149#issuecomment-5848091891) +as a repository-admin bypass restricted to pull requests; the live actor is the +integration, in `always` mode, and the ruleset's `updated_at` is +2026-09-28T06:22Z, after that receipt. Whether the actor or the mode changed +in that update, or the receipt described the same actor differently, is in the +ruleset's history, which the owner can read (Settings → Rules → Rulesets → +"Verified pull requests" → History) and lane credentials cannot (403). Both +documents carry a dated correction. Author-reported, head-associated check +observation: for every one +of the 62 pull requests merged into `main` since 30 September, the check runs +named `verify`, `public-intake` and `public-shop` that GitHub associates with +the pull-request head were at `success` before the merge time (check-run API +read, 2026-10-07 16:30Z; the non-success `public-intake` runs on 34 of those +heads are `pull_request_target` re-runs that started after the merge), and +the 59 first-parent commits in that window (62 pull requests: #241–#243 and +#267–#268 landed as stacked pairs sharing one merge commit each) are 58 merge +commits whose tree equals the mechanical merge of their parents and one +single-parent squash merge, `9677f28` of #232 on 2 October, whose tree equals +the mechanical merge of its parent and that pull request's head `48d03fa`, a +head whose three required checks were at `success` before the merge time. +This does not bind those runs to the tested +merge commit that the required-check contract names, does not verify review +thread resolution at each merge time, and does not establish when the bypass +actor was added (ruleset history returns 403 to lane credentials). Whether the +bypass was ever used is therefore not established from here, in either +direction. The project's own rule is +that required hosted checks remain required at the tested commit for every +lane, so the auditor's recommendation is to remove the bypass. Recording it +here as an accepted exception is the alternative; either is the owner's +decision, and until it is recorded the choice is pending. + +## Owner actions (one time; for the four project repositories nothing else is pending on Dylan for access) + +1. **Cursor Cloud Agents:** in the Cursor dashboard, Cloud Agent settings → + secrets, add `GH_TOKEN` holding a fine-grained GitHub personal access token + limited to `main`, `Math-`, `query-` and `Universal-Law-Workspace`, with + Issues read and write, Pull requests read and write, Contents read and + write and Workflows read and write (Contents alone cannot push a change under + `.github/workflows`, which is routine here); add Actions read and write only + if the lanes should dispatch or re-run workflows. Give it an expiry and record + the date here. The token acts as the owner's user across all four + repositories, so a Cloud Agent honoring it is not limited to the task + repository. This may not be sufficient (see above): + the first Cloud Agent run after the secret exists should attempt one issue + comment on main#229 and report the result, and the fallback below stays + until that succeeds. +2. **`main` ruleset 23798639:** Settings → Rules → Rulesets → "Verified pull + requests" → Bypass list: remove the ChatGPT Codex Connector, or reply on + main#229 that the exception stands and this record will be amended. The + History tab of the same page shows what the 2026-09-28T06:22Z update + changed; one line on main#229 saying so settles when the actor was added. +3. **main#227 clicks** (checked 2026-10-07 15:00Z: `trial` and `sandbox` are + not archived; `google-drive`'s About text is unchanged): the four steps in + [OWNER_DECISION_20261006_SURFACES.md](OWNER_DECISION_20261006_SURFACES.md). +4. **Optional:** in GitHub → Settings → Applications → Cursor → Repository + access, include every project repository. This widens what the + installation may reach, not necessarily what a Cloud Agent's token reaches: + GitHub lets an app + [restrict an installation access token](https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-an-installation-access-token-for-a-github-app) + to a subset of the installation's repositories, and this record's + observation is only that Cloud Agent writes succeeded on the task + repository and failed across repositories; the token's own repository + scope is UNKNOWN. Cross-repository reads + therefore stay UNKNOWN until a Cloud Agent reads one file from another + project repository and reports it. Writes through the installation token + are equally UNKNOWN after this change: a token minted without a repository + restriction covers every repository in the installation, and the + task-repository-only observation above cannot distinguish a restricted + token from an installation that included only that repository. The same + first run should therefore also attempt one pull-request comment on a + second project repository and report both results with their + authentication path, so that the widened installation's write scope is + observed rather than assumed. Record the path actually selected, without + disclosing token material, and the resulting GitHub principal, as separate + facts. A comment that appears as `cursor[bot]` went through the + installation token. An owner-attributed comment alone does not identify + the credential: the `GH_TOKEN` of action 1 and an app's user-access token + both post as the owner's user. `gh` prefers `GH_TOKEN` whenever that + variable is set, so a run that has both must make the probe calls with the + installation token explicitly; when the selected path cannot be + established, installation-token scope stays UNKNOWN. A successful comment + establishes that one operation, not every write. Writes through the + `GH_TOKEN` of action 1, if honored, reach all four repositories. + +## For every lane + +- Report a refusal, do not route around it: the endpoint, the status, the + `X-Accepted-GitHub-Permissions` value when present, and what you did instead. + One line in the delivery comment is enough. +- Keep three things apart: the owner's authority, the tool or harness a lane + actually has, and the operation observed. A granted token or a passing + `gh auth` check is not capability evidence; a successful merge does not show + that issue posting, cross-repository push or workflow dispatch works. Only + an observed operation, labeled by operation, repository, runtime and time, + is; anything uninspected stays UNKNOWN. +- Do not ask Dylan for permission the delegation already grants. Ask him only + for the actions above, and only once they are not yet done. +- Cursor Cloud Agents, until a Cloud Agent's new issue comment is observed to + succeed: record pickups and verdicts in the acknowledgement comment or on the + pull request, and ask a lane that can write to the boards to post tip locks + and board records, as the record already shows. +- Claude sessions: attach the project repositories at the start of the session, + one call per repository. When the harness refuses something, classify the + obstacle before routing any work around it. A denial of an action stays a + denial whatever its wording and whichever operation exposed it: do not + retry it, and do not have another session or lane perform that action in + your place; hold the text for the owner, say so in the record, and carry on + with unrelated authorized work. A tool that is absent, or a request shape + the harness cannot make, is different: there, text that would have been + posted may go to a lane that is authorized to publish it and is not itself + under a denial for that action, with ownership of the work unchanged. + Whether a refusal in another session would recur is not known from this + record (see "Where the refusals come from"). If the scope of a denial is + unclear, pause the affected action and ask for its exact scope; unrelated + work continues. +- Never use a ruleset bypass, and never simulate another identity's approval. + +## Unchanged + +Scientific acceptance conditions, `formal/` and register custody, +[OP-PRIVACY](OP-PRIVACY-20260927.md) and the required-check contract keep their +meaning. A granted permission is not evidence that work succeeded.