Central controls answer whether a change meets security and approval policy. Each Coffee Chat repository answers whether its own product or data is correct. Neither requires the center to know Product Skills, benchmark folders, or an evaluator implementation.
repository-baseline.yml provides workflow syntax, whitespace and secret checks
for newly initialized repositories before a product verification contract is
registered. It is reusable only, accepts no inputs or secrets, and admits
same-repository pull_request_target or main push context. Its stable job is baseline, named
Trusted repository baseline; callers use the name trusted-baseline and an
immutable workflow SHA. Verify the resulting check name and referenced workflow
revision from a live run before requiring that check.
This baseline treats candidate files as data, uses pinned trusted tools and explicit linter/scanner configuration, and does not execute product code. It does not replace the Coffee gate described below, independent review, product tests or approval policy. Introduce it alongside a caller's existing required checks. The separate inert caller must already exist on main before a target run can qualify the producer. Fork PRs are unsupported; no checkout safety override is enabled. See the original contract and accepted remediation.
Workflow paths and their ancestors must be regular files/directories without
symlinks. Each workflow is linted through stdin with a trusted empty config,
so local action metadata is outside this hygiene lane. The explicit integration
check node scripts/test-baseline-actionlint.mjs uses actionlint 1.7.12, selected
with ACTIONLINT_BINARY, to verify path rejection, metadata isolation and normal
syntax checks.
node scripts/test-baseline-gitleaks.mjs explicitly tests deleted historical
credentials against real Gitleaks 8.30.1; set GITLEAKS_TRUSTED_CONFIG to its
checksum-verified configuration. It rejects candidate binary diff attributes
that could otherwise hide history while a directory scan passes. This test is
separate from the offline unit suite because it requires the scanner binary.
- An exact, inert wrapper selects this reusable workflow by immutable SHA.
- Approved central code checks candidate data, existing protected paths, secrets, dependency changes and CodeQL findings. Invalid policy fails immediately.
- Sensitive changes wait for the existing coffee-security approval.
- The repository's npm run verify runs in an isolated container. Installation uses its integrity-locked registry dependencies without lifecycle scripts; candidate programs have no network, token, host mount or runner command files.
- The unchanged required aggregate accepts only explicit successful results. GitHub applies required checks and independent review. Target wrappers retain only pull_request_target; they cannot add push or other execution triggers. Post-merge observation belongs to organization-owned orchestration; the target wrapper itself does not claim an automatic main-push check.
Targets are coffee-chat (Product), coffee-chat-roastery (public data seed), coffee-chat-bench (evaluation definitions), and coffee-chat-eval (execution/evidence). The project owner is SonSangjoon. Existing team ownership remains in CODEOWNERS; the PR author cannot supply their own independent review.
Run npm run verify, actionlint (all workflow extensions), shell/Node syntax checks and git diff --check. scripts/test-isolation.mjs additionally exercises the real Docker boundary; it is explicit because unit-test containers cannot access the host Docker socket. The pinned installer for actionlint verifies its SHA256. The test suite covers malformed control data, protected-path removal, workflow spoofing, installation authority, approval and cancelled/missing job results.
Trusted CI for this repository uses base-owned controls to execute candidate regressions in isolation. Do not add a candidate-owned pull_request workflow as a bootstrap: its author can change the host-runner steps before any guard or container runs. The workflow inventory test detects drift during verification; it is not a GitHub pre-execution enforcement barrier for new workflow files.
The first introduction cannot retroactively create base-owned CI on the old base. Before requesting owner approval, complete latest-head Codex review, resolve code findings, and retain exact-tree local regression, lint, secret-scan and real-isolation evidence. Report missing GitHub CI as unverified, not passing; do not create a substitute success check or bypass existing required checks. The owner must review the initial landing, including this evidence gap. After landing, observe trusted main CI before upgrading callers. Subsequent central PRs require the base-owned CI as well as Codex review. Source commits in support are full SHAs, not branch names. An old caller still uses its old pin on a rerun.
Do not weaken a required check to change its implementation. Keep the canonical PR-only wrapper shape unchanged, validate each target's actual base/head, then update only its immutable control SHA. Existing protected paths, secret hooks, update policy and required-check identity are retained. Changes to those safeguards require an explicitly reviewed successor contract, not approval of an unrelated failure.
Use .github/scripts/audit-ci-settings.mjs to inspect live settings. It is read-only and uses GitHub's effective main rules, including exclusions and inherited rules, instead of treating declarations as enforcement. Missing ruleset/bypass details remain unverified. CODEOWNERS keeps one location and its existing ordered routes as a suffix; new routes go before them so they cannot override existing owners. Owner additions use GitHub user/team handles; malformed tokens fail because they can invalidate an entire route. Comments preserve those routes. Any initial blocked-pin exception must be scoped to an exact PR/base/head/control SHA, expire, include compensating verification and leave all protections restored. Existing code-quality/coverage rules are not deleted by this rollout; their producers must be verified before claiming success.
Local tests, live GitHub checks, owner approval, merged main and post-merge runs are separate evidence states. No passing CI check is a Ground Truth approval, Judge qualification, evaluator calibration or Product-performance result.