web_issue trigger omits request context — agent cannot learn the ask (least-privilege token has no issues:read)

[javiertoledo]

Found while dogfooding the platform lane on a live deployment.

What happened

Triggering an agent from the control plane (POST /v1/projects/:projectId/issues/:number/trigger, trigger type web_issue) creates a run whose trigger payload carries only the issue number — unlike the GitHub-comment path, where routeTrigger embeds request: githubRequestContext(payload) precisely because "without this context an agent only received numeric GitHub IDs and could not know what work the user requested".

The architect then tried every channel to learn the ask and hit walls by design:

• GitHub REST via the run's installation token → 403 Resource not accessible by integration (run-scoped token is minted least-privilege, no issues:read, even though the App installation itself has issues: write).
• Facility platform API via $FACILITY_PLATFORM_KEY → 403 forbidden (key lacks issues:read / projects:read / tasks:read).

The agent (correctly) refused to fabricate a plan and stopped at Human Gate 1 asking for the issue text. Evidence: run run_019f8177e2b671a2a3052fe29bef8a2d, the run’s progress comment.

Expected

A web_issue-triggered run should be self-sufficient: embed the synced issue title/body from ghIssues into the trigger (the platform already has it — the issue is synced), mirroring githubRequestContext. Alternatively (or additionally), scope the run's platform key to read its own triggering issue.

Why it matters

The web trigger is the UI's primary affordance; today it produces a run that cannot know what was asked, which reads as a broken product experience unless the user happens to know the comment path works differently.

[elirethDev]

Verified against main (ae68401): this is fixed, and there is a regression test pinning it.

The web_issue trigger path now embeds the full issue context in the run:

• services/api/src/routes/v1/github.ts loads the synced GitHub issue (title, body, user, labels, url) plus its comments, builds issueRequest via githubRequestContext(...), size-asserts it, and stores it in the run trigger as request (lines 959-996).
• services/api/test/github-platform-lane.test.ts:3172-3189 pins the behavior: a POST /v1/projects/:projectId/issues/44/trigger run must carry trigger.request with title, body, author, url, labels, and comments.

With the request embedded in the run, the agent no longer needs issues:read to learn the ask, so the alternative of scoping the run platform key is not required for the core problem.

Suggest closing this as fixed.

[alvaroloes]

Fresh private-repository canary evidence on 2026-08-26 suggests this boundary still needs an end-to-end regression even though current source now loads issue comments for the Story trigger.

Sequence observed:

1. A substantive /architect revision comment was visible in the Facility Story.
2. The previous proposal was rejected.
3. Architect was triggered from the Story/control plane.
4. The new run completed and opened plan_acceptance, but its durable proposal did not apply the revision requirements: it reverted to the earlier open decisions and again delegated required detail to an ephemeral plan file.

I cannot distinguish from the hosted UI alone whether the deployed trigger omitted/truncated the latest comment or the agent received it and ignored it; deployed-build provenance is separately unobservable. Either way, today's acceptance check can mark the run successful and open Gate 1 without proving that the proposal corresponds to the latest substantive issue revision.

A useful regression would:

• add a unique substantive revision comment after proposal P1;
• trigger Architect through the Story endpoint;
• assert the exact comment is present in the immutable run.trigger.request.comments snapshot;
• record a canonical issueRevisionSha256 on the proposal;
• reject proposal opening/acceptance when that digest is missing or no longer current;
• exclude only Facility progress comments and command-only /builder noise from the digest.

This composes with #147/#166 for base provenance and #204 for required-plan dispatch. No private repository, account or plan content is included here.

[ophiocus]

@alvaroloes — your six bullets read as a complete spec, and five days seemed long enough to ask: is anyone building it? If not, I'd like to.

The shape I'd propose, test-first so the canary sequence you observed can never pass silently again:

1. The e2e regression exactly as written: proposal P1 → unique substantive revision comment → Architect via the Story endpoint → assert the comment verbatim inside the immutable run.trigger.request.comments snapshot.
2. issueRevisionSha256 recorded on the proposal at creation, computed from the trigger snapshot the agent actually received — so "deployed trigger omitted it" and "agent ignored it" stop being indistinguishable from the UI: the digest tells you which.
3. Acceptance gate: plan_acceptance refuses to open/accept when the digest is missing or no longer matches the issue's current substantive revision — same family as the existing Builder freshness gate, one stage earlier.
4. Noise exclusion per your last bullet — which is the Facility queue acknowledgement comments can make approved Builder plans stale #222 lesson generalized: markerless Facility queue acks already poison revision comparisons, so the digest input takes only substantive human content (Facility progress markers and command-only comments excluded by the same predicate, shared, not duplicated).

Composition checked before writing this: #234 (ReviewContextV1) snapshots what the approver saw and this gates on what the agent received — they meet at the same acceptance event without overlapping, and I'd copy the digest into the same self-contained event record #234 establishes. Also composes with #147's base-commit provenance, as you noted.

If you or anyone inside is already on it, say so and I'm gone — otherwise I'll bring it the way #195 went in: the failing test first, then the mechanism, both platforms green.