Owner walkthrough
This page follows a repository owner from choosing a policy to a merged PR. Each step says what the file or action is, why it exists, who maintains it, and where the public evidence is. All links are listed in ../evidence/sources.json.
1. Select the policy
File: .fullsend/config.yaml in the consumer repository.
auto_merge:
mode: shadow
policy: fullsend-default
controls:
- OSPS-QA-03.01- Why it exists. It is the owner's single statement of intent.
modeisoff,shadoworenforce.policynames the shared policy.controlsadds optional maintained requirements. - Who maintains it. The repository owner. A managed installation sets the same block under the repository's
config:inrepos.yaml, or underdefaults.configto inherit it. Management then writes.fullsend/config.yaml; do not edit a managed file by hand. - Inheritance.
offoverrides an inherited enablement.controls: []clears inherited optional selections. - Status. This schema is local experimental work. A modified Fullsend build, carried as a vendored binary with recorded provenance and a source patch, materialized these settings. It also supported
fullsend auto-merge configto inspect the effective configuration. It is not a released Fullsend feature.repos.yamlhandling was tested only locally. - Limits.
enforcealone cannot mint authority or renew an expired grant. Adding an arbitrary upstream control is not plug-and-play: each one needs a trusted implementation and evidence adapter. The lab's owner flow for adding a control describes what this one required.
The quality threshold, window and freshness live in separate trusted consumer configuration and are loaded from the protected base, never from the candidate branch. See quality-policy-9900.json and quality-policy-9000.json for the synthetic shapes.
2. Issue
Issue #57 describes the documentation change. Keep the demonstration issue separate from setup and owner-scope changes, because mixing them caused review friction in earlier attempts.
3. PR
PR #58 implements the change, touching only owner-allowed documentation paths. OWNER-SCOPE checks those paths against the binding: governed paths such as .github/**, .fullsend/** or policy/** hold, even for a one-line change.
4. Review on the current head
Fullsend Review run 39955761534 reviewed head 14499514… with trusted configuration 5f4f8f39…. It reported an approval, no unresolved findings and low risk. The review-evidence contract and GitHub evidence collector turn this output into the normalized observation. Without a risk assessment, REVIEW-CLEAR is Unknown and the PR holds (replay S04).
5. Assessment
The automatic evaluation workflow (run 39956959534) runs the pinned shared evaluator through the shared gate adapter, inside a separate execution boundary with no write credential. It then adds the quality check and the selected OpenSSF requirement. The result is AND-composed: one Failed or Unknown means hold.
Open the artifact and read its decision. A green workflow job only means the observation completed; the decision inside can still be hold.
Try it offline: scripts/reproduce.sh (see the README). S01 shows a 99% hold, S02 shows 90% eligibility, and S05 shows the OpenSSF requirement.
6. Writer and queue enrollment
The trusted authorizer and existing App writer are separate from assessment. They revalidate, obtain a short-lived repository-scoped token and request protected-queue enrollment: job 120426280311. The timeline shows the App adding PR #58 to the queue at 12:58:50 UTC. Eligibility is necessary but never sufficient. Shadow mode, a missing grant or an expired grant prevents any write (replay S08, mock only).
7. Queue validation on the combined revision
Merge-queue validation (run 39957499141) and CI 39957499387 assess fee00797…, the revision that would land. That is not the reviewed head 14499514… (replay S09).
8. Merge
GitHub's merge queue merged PR #58 at 13:03:51 UTC on 2026-10-23 as fee00797. Gemara assessed. GitHub merged.
9. Cleanup
Commit 4c86073e set the mode back to shadow and disabled grants, and CI 39958588002 passed. The read-only shadow observation workflow can still evaluate PRs without needing or using merge authority.
