feat(copilot): add a pull-request integrity check for GitHub Copilot

[imran-siddique]

The fourth engine, and the first one that is not a session hook.

Why the shape is different

Copilot's composition lives in the repository. Its instructions, skills and MCP configuration are files that arrive by pull request.

The Claude Code and Codex integrations watch a developer's machine and warn at session start, after the fact, one developer at a time. They have to: that composition lives in a home directory. Here it is reviewed code, so drift can be caught on entry:

• One baseline, shared. Committed at .agentrust/copilot-baseline.json, not one per laptop.
• Reviewed like code. A change to the agent's instructions appears in a diff, with an author.
• Enforceable. As a required check, a pull request that changes the agent's behaviour without updating the baseline does not merge.

CODEOWNERS for the agent's brain, roughly.

The surface is wider than I expected

I said I would verify the paths against GitHub's docs before building, and it changed the design:

Category	Paths
Instructions	.github/copilot-instructions.md, .github/instructions/**/*.instructions.md, AGENTS.md anywhere in the tree, root CLAUDE.md and GEMINI.md
Skills	.github/skills/<n>/, .claude/skills/<n>/, .agents/skills/<n>/
MCP	copilot/mcp-config.json, .vscode/mcp.json

AGENTS.md is matched anywhere, because Copilot resolves the nearest one. A file three directories down changes how the agent behaves in that subtree without touching anything at the root, and that is precisely the change worth catching. Vendored directories are skipped, so a dependency shipping its own AGENTS.md is not counted as yours. Tested both ways.

Skills are digested across the whole directory via the shared core, so the bypass that was live in two other engines (#63, #65) does not reappear. Copilot skills use the same SKILL.md plus supporting-files shape, so it would have.

Two deliberate omissions, both load-bearing

No baseline sealing, unlike the other three. They seal because a local baseline can be rewritten with nothing to show for it. A committed baseline gets provenance from git: every change appears in a diff, carries an author, passes review. A digest on top would be ceremony, and shipping ceremony as security is the habit this repo argues against.

No integration.yaml. The schema requires integrates_with to be one of cmcp, trace or agent-manifest. This check emits none of them, so claiming one would be an unverifiable claim, and CONTRIBUTING rule 2 is explicit about those. The README says so plainly and names emitting a TRACE record per checked pull request as what would make one true. That is also the natural first consumer for trace-registry.

Worth noting the schema assumes every integration integrates with the AgenTrust stack. A drift checker that uses the shared core but emits no record has no honest value to put there, which may be a gap in the schema rather than in this integration.

Adoption details that matter more than they look

• A missing baseline reports and exits 0. A repository adopting this should not have its first pull request blocked by the absence of a file nobody told it to create.
• fail-on-drift can be turned off. Report without blocking is the sensible first move on a busy repo; flip it on once the baseline settles.
• One comment per pull request, edited in place. A comment per push is noise people mute.
• No install step. Engine plus vendored core are standard library only.

Test plan

• 25 tests, standard library only. All three skill roots, nested .github/instructions, AGENTS.md at depth, vendored AGENTS.md excluded, the skill-script bypass, state churn not alarming, both MCP paths, and verify's exit codes as a status check.
• Dogfooded: snapshot and verify run against this repository in CI. It currently has none of these surfaces, so the counts are zero and verify says there is no baseline. Honest, and it becomes a real gate on ourselves once one is committed.
• ruff check --target-version py39 clean. Vendored sync check passes across all four engines.

One repo-wide problem I hit and worked around. Four engines each define a module named capture, so sys.path insertion made this suite run against another engine's code when the repository is collected in one pytest command: 25 failures against the wrong module. This suite now imports its engine by path under a unique name, and is named test_copilot_capture.py so it does not join the pre-existing test_capture.py basename collision between the other three. A single root-level pytest still fails on that older collision, which predates this PR and deserves a follow-up.