No wrapper edits a PR body (issue-edit.sh has no PR equivalent) — blocks a seat from correcting its own declared contract #979

Open
opened 2026-07-31 03:10:23 +00:00 by Mos · 0 comments
Contributor

There is a wrapper to edit an issue body (issue-edit.sh) but none to edit a pull request body.

Observed

A coder seat was instructed to refresh a stale contract section in a PR description — documentation only, no code change. It correctly stopped at the wrapper gate and did not fall back to raw tea/API:

$ ~/.config/mosaic/tools/git/pr-view.sh 3107
exit 1, no output

(That specific failure was a usage error — pr-view.sh requires -n <number>, not a positional. But even with correct syntax, pr-view.sh only reads.)

Full inventory of PR wrappers: pr-ci-wait, pr-close, pr-create, pr-diff, pr-list, pr-merge, pr-metadata, pr-review, pr-view. None edits a PR body.

Why this matters more than it sounds

The PR body is where the declared contract lives — the thing reviewers, validators, and merge gates check against. On the PR in question, a marker's declared line number drifted 171 → 183 → 206 across three heads while the invariant literal stayed fixed. An external validator greps that literal; a reviewer reads that contract. A stale body is a stale gate input.

Under the hard gate ("use the Mosaic git wrappers before any raw provider CLI; if a required wrapper command fails, status is blocked"), a seat that needs to correct its own declared contract cannot, and must escalate to whoever holds a raw credential. That is the correct behaviour given the rule, and it means the rule currently forbids a routine, low-risk documentation fix.

Required

Add pr-edit.sh covering at minimum --body and --title, mirroring issue-edit.sh's interface and its login/slug resolution.

And build it with the readback this family is missing (#976, #977, #978): assert the edit is present by re-reading the PR after the write, and make the success line conditional on that. Do not repeat the pattern where the tool prints success for an effect that never occurred.

Note also that tea has no issue comment subcommand (#976); confirm which PR-edit verbs tea actually exposes with tea pr --help before wiring the implementation, rather than assuming a verb exists because it is spelled like its siblings.

There is a wrapper to edit an **issue** body (`issue-edit.sh`) but **none to edit a pull request body**. ## Observed A coder seat was instructed to refresh a stale contract section in a PR description — documentation only, no code change. It correctly stopped at the wrapper gate and did **not** fall back to raw `tea`/API: ``` $ ~/.config/mosaic/tools/git/pr-view.sh 3107 exit 1, no output ``` *(That specific failure was a usage error — `pr-view.sh` requires `-n <number>`, not a positional. But even with correct syntax, `pr-view.sh` only **reads**.)* Full inventory of PR wrappers: `pr-ci-wait`, `pr-close`, `pr-create`, `pr-diff`, `pr-list`, `pr-merge`, `pr-metadata`, `pr-review`, `pr-view`. **None edits a PR body.** ## Why this matters more than it sounds The PR body is where the **declared contract** lives — the thing reviewers, validators, and merge gates check against. On the PR in question, a marker's declared line number drifted **171 → 183 → 206** across three heads while the invariant literal stayed fixed. An external validator greps that literal; a reviewer reads that contract. A stale body is a stale gate input. Under the hard gate (*"use the Mosaic git wrappers before any raw provider CLI; if a required wrapper command fails, status is blocked"*), a seat that needs to correct its own declared contract **cannot**, and must escalate to whoever holds a raw credential. That is the correct behaviour given the rule, and it means the rule currently forbids a routine, low-risk documentation fix. ## Required Add `pr-edit.sh` covering at minimum `--body` and `--title`, mirroring `issue-edit.sh`'s interface and its login/slug resolution. **And build it with the readback this family is missing** (#976, #977, #978): assert the edit is present by re-reading the PR after the write, and make the success line conditional on that. Do not repeat the pattern where the tool prints success for an effect that never occurred. Note also that `tea` has no `issue comment` subcommand (#976); confirm which PR-edit verbs `tea` actually exposes with `tea pr --help` **before** wiring the implementation, rather than assuming a verb exists because it is spelled like its siblings.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#979