docs(fullsend): CI install, dispatch design, and upgrade procedures (TC-6193)

[mrizzi]

Summary

Documents the deployed verify-pr fullsend install and day-2 operations in fullsend.md (TC-6180 Req 16). Docs-only change.

• CI deployment (per-repo GitHub App) — new section: fullsend github setup, fullsend inference provision (hosted Vertex via WIF), and org GitHub App install.
• Dispatch design — why pull_request + lewagon/wait-on-check-action (inline CI wait) instead of check_suite/check_run/workflow_run; CI-result-is-data-not-a-gate; the CEL trigger on the composing child; pre_script Jira JQL gating.
• Variables and secrets (day-2 management) — table of every CI vars.* / secrets.* (incl. the Jira Service Account JIRA_EMAIL / JIRA_API_TOKEN) with how/when to rotate each.
• Bumping the fullsend version — pin lives in the dispatch workflow (fullsend_version: "v0.43.0"); bump + re-validate procedure.
• Keeping the two plugin-version files in sync — plugin.json + marketplace.json bumped together.
• Refreshed stale v0.37.0 framing in the intro/prerequisites.

Verification

Reviewed for accuracy against the deployed sources: .github/workflows/fullsend-verify-pr.yml, .fullsend/config.yaml, .fullsend/config.base.yaml, .fullsend/harness/verify-pr.yaml, and the two version files. CI checks (CONVENTIONS.md) all green: pytest 147 passed, claude plugin validate ✔, skillsaw 0 errors.

Implements TC-6193

🤖 Generated with Claude Code

Summary by Sourcery

Document how to deploy, operate, validate, and upgrade the fullsend verify-pr workflow in CI.

Enhancements:

• Document the deployed fullsend verify-pr CI installation, post-installation operations, dispatch behavior, configuration management, and upgrade procedures.

Documentation:

• Refresh the fullsend guide to describe CI deployment, CI-gated dispatch semantics, Jira gating, variable and secret rotation, CLI version bumps, and synchronized plugin-version updates.

[sourcery-ai]

Reviewer's Guide

Expands fullsend.md from basic usage and release notes into an operational guide for the deployed verify-pr CI integration, covering provisioning, CI-gated dispatch behavior, credentials and variable rotation, version upgrades, and synchronized plugin releases.

Sequence diagram for CI-gated verify-pr dispatch

sequenceDiagram
    participant PR as Pull Request
    participant Actions as fullsend-verify-pr.yml
    participant Checks as Other CI Checks
    participant Dispatch as reusable-dispatch.yml
    participant App as GitHub App
    participant Harness as fullsend run
    participant Jira as Jira

    PR->>Actions: opened, synchronized, or reopened
    Actions->>Checks: wait-on-check-action
    Checks-->>Actions: Terminal results, pass or fail
    Actions->>Dispatch: Dispatch verify-pr review matrix
    Dispatch->>App: Mint review-role token via OIDC
    Dispatch->>Harness: Run verify-pr
    Harness->>Jira: pre_script JQL gating
    Jira-->>Harness: Review status and ai-generated-jira label
    Harness->>Jira: post_script report comment

Loading

File-Level Changes

Change	Details	Files
Document the deployed CI installation and dispatch architecture for automated verify-pr runs.	Describe per-repo GitHub App setup, hosted Vertex provisioning through WIF, and org-level App installation. Explain the pull-request trigger with inline check waiting, terminal CI conclusions, concurrency behavior, reusable workflow dispatch, child-level CEL triggers, and Jira pre-script gating.	fullsend.md
Add day-2 operational guidance for CI configuration and credential rotation.	Inventory GitHub Actions variables and secrets with their purposes and rotation conditions. Document Jira Service Account Basic-auth handling and tier-1 credential boundaries.	fullsend.md
Document release and upgrade procedures for the fullsend CLI and plugin metadata.	Explain updating and end-to-end validating the v-prefixed CLI pin in the dispatch workflow. Require synchronized version updates for plugin.json and marketplace.json, and distinguish them from harness re-pinning and re-locking.	fullsend.md
Refresh version references and deployment verification details.	Replace stale v0.37.0 framing with the native CLI path and current CI v0.43.0 pin. Update the verification narrative to identify the configured tier-1 Jira account as the report commenter.	fullsend.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 1 issue

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="fullsend.md" line_range="145-147" />
<code_context>

+## CI deployment (per-repo GitHub App)
+
+The same pinned harness that runs locally is dispatched automatically in CI, once
+per pull request, after the PR's other checks finish. Three one-time provisioning
+steps stand this up (day-0, run by a repo/org admin); the recurring run then needs
+no manual step.
+
</code_context>
<issue_to_address>
**nitpick:** The installation section says the workflow runs once per pull request, but `fullsend-verify-pr.yml` triggers on every `opened`, `synchronize`, and `reopened` event, so a PR receives a run for each qualifying update rather than only one run in its lifetime. This misleads operators about expected dispatch frequency and report behavior.

**Triggers:** When a PR is pushed to or reopened after its initial creation.

**Suggested fix:** Say that the workflow runs once per qualifying PR event/head revision, with newer runs superseding older ones through the concurrency group.

```suggestion
The same pinned harness that runs locally is dispatched automatically in CI once
per qualifying PR event/head revision, after the PR's other checks finish. Newer runs
supersede older ones through the concurrency group. Three one-time provisioning steps stand this up (day-0, run by a repo/org admin); the recurring run then needs
```
</issue_to_address>

Sourcery assessment

Approved.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

[sourcery-ai]

nitpick: The installation section says the workflow runs once per pull request, but fullsend-verify-pr.yml triggers on every opened, synchronize, and reopened event, so a PR receives a run for each qualifying update rather than only one run in its lifetime. This misleads operators about expected dispatch frequency and report behavior.

Triggers: When a PR is pushed to or reopened after its initial creation.

Suggested fix: Say that the workflow runs once per qualifying PR event/head revision, with newer runs superseding older ones through the concurrency group.

Suggested change

	The same pinned harness that runs locally is dispatched automatically in CI, once
	per pull request, after the PR's other checks finish. Three one-time provisioning
	steps stand this up (day-0, run by a repo/org admin); the recurring run then needs
	The same pinned harness that runs locally is dispatched automatically in CI once
	per qualifying PR event/head revision, after the PR's other checks finish. Newer runs
	supersede older ones through the concurrency group. Three one-time provisioning steps stand this up (day-0, run by a repo/org admin); the recurring run then needs

[mrizzi]

Superseded by #305 — reopened with the head branch on the upstream repo so the verify-pr pull_request dispatch gets secrets + OIDC and can run.