Governance proposal: extend cross-repo mandate from filing issues to opening PRs

[rosscado]

Problem: Cross-repo contract changes that require the server side to change are escalations: the agent may file issues on saypi-api/saypi-saas but not open coordinated PRs, so contract work stalls on coordination.

Scope: Governance proposal for founder decision — extending the cross-repo mandate from filing issues to opening (not merging) PRs on saypi-api/saypi-saas. The server repos' own gates would still govern merge.

Reproduction / verification: AGENTS.md high-blast-radius list routes server-must-change contracts to founder escalation; the cross-repo grant (2026-06-13) covers issues only. Verify done = proposal drafted, founder decision recorded.

Acceptance criteria:

• A written proposal with guardrails (open-only; server repo's review/merge gates apply; client-side stays behind its existing gates).
• Founder decision recorded on this issue.
• If granted: codified in AGENTS.md via PR with the grant date (the standing pattern for durable grants).

[rosscado]

Proposal (for founder decision): extend the cross-repo mandate from filing issues (granted 2026-06-13) to opening pull requests on saypi-api and saypi-saas.

Why: contract changes that need the server side to change currently stall as coordination questions — the client agent can describe the change precisely but must wait for a sibling agent or the founder to pick the issue up. Both server repos already run under the same autonomous operating model, so a well-formed PR is a better coordination artifact than an issue restating what the PR would contain.

Proposed guardrails:

1. Open-only, never merge. The server repo's own merge gates, reviewer conventions, and AGENTS.md govern entirely; the client agent never merges, approves, closes, or relabels anything in the server repo beyond its own PRs.
2. Coordinated pairs. A cross-repo PR must backlink its client-side counterpart (and vice versa), state the compatibility order (which side can ship first), and keep both sides independently revertible — no flag-day contracts.
3. Same hygiene as home: isolated branch, claim comment on the target repo's issue, full provenance, never touch another agent's branch/worktree there, never read that repo's production secrets.
4. Scope: contract-adjacent changes only (endpoints/fields/headers the client consumes, plus the tests/docs those need) — not general feature work in the server repos.
5. High-blast-radius symmetry: anything the server repo's constitution founder-gates stays founder-gated there; this grant doesn't tunnel around it.

The ask (@rosscado): grant / amend / decline. If granted, I'll codify it in this repo's AGENTS.md with the grant date (and file an issue on saypi-api/saypi-saas so their constitutions acknowledge inbound coordinated PRs).

Leaving this open with awaiting-founder until you decide.

[github-actions]

@rosscado — this is now awaiting a founder decision or sign-off (awaiting-founder applied by @rosscado). See the latest comment/description for what's being asked. Standing queue: open items with this label.

[rosscado]

Approved by founder.