mosaicstack/stack
1
0
Fork 0
Code Issues 81 Pull Requests 1 Actions Packages Projects Releases 15 Wiki Activity

framework git wrapper: Gitea comment action silently posts nothing #812

New Issue
Open
opened 2026-07-17 00:49:59 +00:00 by jason.woltje · 0 comments
jason.woltje commented 2026-07-17 00:49:59 +00:00
Owner
Copy Link

Summary

packages/mosaic/framework/tools/git/pr-review.sh reports success for the Gitea comment action even though no comment is posted.

Root cause

The Gitea branch invokes:

tea pr comment <number> <comment> ...

The installed Tea CLI has no pr comment subcommand. It falls back to displaying/listing pull requests, exits zero, and the wrapper then prints Added comment to Gitea PR #<number>.

Integrity impact

A caller can believe a durable reviewer-of-record or gate comment exists when Gitea persisted nothing. This creates a false-positive provenance gate and can permit a merge without its required durable artifact unless the comment is independently read back.

This is distinct from #795, which concerns Codex PR-mode diffing the wrong branch.

Acceptance criteria

  • Gitea comment uses a supported Tea/API operation and targets the named PR.
  • The wrapper fails nonzero when persistence fails.
  • The wrapper reads back the created comment and verifies repository, PR number, and exact body or returned comment ID before reporting success.
  • A regression test proves the current nonexistent-subcommand/fallback behavior cannot return success.
  • Existing approve and request-changes behavior remains covered.
  • Documentation states that write-wrapper output alone is not durable provenance until provider read-back succeeds.

Verified interim discipline

Read back the PR comments from Gitea and verify the exact-head reviewer artifact exists before queue guard or merge. Never trust the wrapper success echo alone.

OpenBrain framework-improvement capture: 5c2eb047-ca18-42bb-9b46-51f9fa8bb1d9.

## Summary `packages/mosaic/framework/tools/git/pr-review.sh` reports success for the Gitea `comment` action even though no comment is posted. ## Root cause The Gitea branch invokes: ```text tea pr comment <number> <comment> ... ``` The installed Tea CLI has no `pr comment` subcommand. It falls back to displaying/listing pull requests, exits zero, and the wrapper then prints `Added comment to Gitea PR #<number>`. ## Integrity impact A caller can believe a durable reviewer-of-record or gate comment exists when Gitea persisted nothing. This creates a false-positive provenance gate and can permit a merge without its required durable artifact unless the comment is independently read back. This is distinct from #795, which concerns Codex PR-mode diffing the wrong branch. ## Acceptance criteria - [ ] Gitea `comment` uses a supported Tea/API operation and targets the named PR. - [ ] The wrapper fails nonzero when persistence fails. - [ ] The wrapper reads back the created comment and verifies repository, PR number, and exact body or returned comment ID before reporting success. - [ ] A regression test proves the current nonexistent-subcommand/fallback behavior cannot return success. - [ ] Existing `approve` and `request-changes` behavior remains covered. - [ ] Documentation states that write-wrapper output alone is not durable provenance until provider read-back succeeds. ## Verified interim discipline Read back the PR comments from Gitea and verify the exact-head reviewer artifact exists before queue guard or merge. Never trust the wrapper success echo alone. OpenBrain framework-improvement capture: `5c2eb047-ca18-42bb-9b46-51f9fa8bb1d9`.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
jason.woltje
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#812
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?