Hard guardrail: block pull-request creation on direct-push-only repos

[proagentstore]

Problem: run cda38e26 (working issue #806) opened pull request #819 on ProAgentStore/platform, even though this repo's whole workflow is direct-push-to-main with no branches and no PRs. The objective text told the run not to do this, and it did anyway, apparently under pressure near its iteration limit.

Relying on the objective's prose to prevent this every single run is fragile - it already failed once. This should be enforced structurally.

Requested feature: a per-repo (or per-instance) flag, e.g. repo.disallowPullRequests, that when set causes the platform to reject/block the github_create_pull_request tool call outright (or intercept the underlying git push of a non-default branch intended for a PR) with a clear error the engine can read and recover from, rather than letting the PR get created and only catching it in a later cleanup run.

Acceptance criteria:

1. A repo can be flagged as direct-push-only via console or MCP tool.
2. When flagged, an attempt to create a pull request via the connector's github tool is refused with an explanit error rather than silently succeeding.
3. The refusal message tells the engine what to do instead (push directly to the default branch once checks pass).
4. Existing repos default to unflagged (no behavior change) unless explicitly set.
5. Tests covering: flagged repo blocks PR creation, unflagged repo is unaffected.

Motivation: ProAgentStore/platform itself is direct-push-only, and this failure mode (a run opening a PR nobody asked for, requiring a manual cleanup pass) has already happened once and cost an extra continuation run to fix.

[serge-ivo]

Delivered on main — commit 1d95ef50

Implemented as a fourth MergePolicy value, direct, rather than a separate
repo.disallowPullRequests flag. Two competing per-repo booleans would have made
"what may this agent do with this repository" a question with two sources of truth;
direct reuses the merge-authority gate built for #314, which is already wired into the
Pilot's prompt, its instruction screen, and the observed-act check.

One correction to the issue, because it changes where the fix had to go

AC 2's mechanism does not exist. There is no github_create_pull_request tool on
this platform to block. The github connector's ten tools are read-only plus
github_create_issue / github_comment_issue / github_update_issue
(workers/api/src/lib/connectors/github.ts:364-474), and repo_git's argv is fixed to
status|diff|diff-stat|log|ls-files|show (repo-local.ts:556). Across all 60 connector
tools nothing can open a pull request.

PR #819 was opened by the Engine — Claude Code running gh pr create in a terminal
session under --dangerously-skip-permissions. The runner already classifies that
command as act kind pr.open
(packages/browser-runner/src/coding/engine-acts.test.ts:40), which is what made this
enforceable at all.

direct is the mirror of pr, not a rung above it

merge > pr > none is decreasing permission over the trunk. direct permits the
trunk — that is the point of it — and forbids the pull request instead. Nothing may sort
this union or read a later member as stricter. The three layers carry it unchanged:

Layer	Under direct	Enforcement
1 · authorityInstruction	"commit on the default branch and push directly to it once the checks pass… must NOT open a pull request"	advisory
2 · screenInstruction	the Pilot cannot relay gh pr create / "open a PR" / "raise a pull request" to the Engine	deterministic, cloud-side
3 · unauthorizedActs	an observed pr.open halts the run, logs act.unauthorized at error, raises a needs_human board card	protocol fact, post-hoc

Layer 2 is the one that sits in front of the actual incident — #819 was opened by an
Engine the Pilot had instructed — and it is a deterministic refusal rather than a
request.

pr.merge is deliberately not forbidden under direct: a repo that delivers by
pushing to main permits putting code on the trunk, so merging a PR a human opened is
the permitted act arriving by an unusual door. What is forbidden is manufacturing the PR.

Against the acceptance criteria

1. Settable via console or MCP — ✅ at the agent level. Migration 0154 adds the
   option to the seeded merge_policy select, and both the console "Agent settings" card
   and MCP set_instance_settings validate against a select's options
   (lib/instance-settings.ts:17), so both accept it as soon as the migration runs.
   ⚠️ The per-repo override is still API-only (PUT …/coding/repos/{repoId}, which
   already accepted mergePolicy). There is no console field and no MCP tool for the
   per-repo value — a pre-existing [safety] Nothing decides whether an agent may merge to main — three unattended merges already happened #314 gap that direct inherits rather than one this
   introduced. Worth a follow-up if per-repo granularity is wanted from the UI.
2. PR creation refused with an explicit error — ✅ at the two points that exist:
   layer 2 refuses to relay the instruction, layer 3 halts the run on the observed act.
   Not via "the connector's github tool", which has no such tool.
3. The refusal says what to do instead — ✅ "Push the work directly to the default
   branch once the checks pass, and say that is what you did."
4. Existing repos default unflagged — ✅ DEFAULT_MERGE_POLICY stays merge, the
   column still defaults to '' (inherit), and merge and pr both still permit
   pr.open. There is no schema change: coding_repos.merge_policy carries no CHECK
   constraint, so a repo override of direct already stored and already resolved.
5. Tests — ✅ 14 new assertions in coding-authority.test.ts (44 in the file), split
   into flagged-blocks and unflagged-unaffected, including an explicit
   "direct permits the trunk — it is not a stricter pr" case.

The honest limit, unchanged from #314

None of this is a kernel-level block. The Engine runs with
--dangerously-skip-permissions on the owner's own machine, so gh pr create remains
physically available to it; layer 3 catches it after the fact and stops the run.
And layer 3 sees nothing on a raw Codex/Grok session — only a stream-json engine
reports the tool_use events acts are derived from, so on those engines direct is
layers 1 and 2 only. describeAuthority states this in the run note the owner reads.
A true pre-execution refusal needs the Engine launched with the command denied to it,
which lives in the runner.

Gates

11,881/11,881 tests, tsc --noEmit (api + workspace), biome, docs:drift,
check-migrations --require-history, check-surface-lock, check-mcp-parity,
check-file-size, check-doc-citations, check-bare-catch,
check-typecheck-coverage, check-test-isolation, check-agents-allowlist,
check-console-types — all green.

One guard had to be taught rather than loosened: repo-path-writer.test.ts walks every
migration to resolve each agent's settingsSchema field ids, and threw on 0154 with
"teach the parser, do not delete the assertion." 0154 appends an option to an
existing field and provably changes no field, so the walk now recognises that shape as a
no-op — guarded on the absence of the two shapes that do change the field set.