|
| 1 | +# GitHub Mission Request Ingress Contract |
| 2 | + |
| 3 | +## Purpose |
| 4 | + |
| 5 | +Define the replayable Keeper ingress policy for formal mission requests sourced |
| 6 | +from GitHub issues. |
| 7 | + |
| 8 | +## Activation Rule |
| 9 | + |
| 10 | +A GitHub issue becomes a formal mission request candidate only when: |
| 11 | + |
| 12 | +- the title begins with `Keel Mission Request:` |
| 13 | +- the body conforms to the canonical mission request template |
| 14 | +- Keeper can read the issue and its current revision through the configured |
| 15 | + provider credentials |
| 16 | + |
| 17 | +Anything that fails these checks remains ordinary issue traffic and must not be |
| 18 | +lowered into a Keel mission request. |
| 19 | + |
| 20 | +## Normalized Ingress Record |
| 21 | + |
| 22 | +Every accepted GitHub candidate lowers into a canonical ingress record with: |
| 23 | + |
| 24 | +- the provider-neutral mission request envelope |
| 25 | +- repository and issue identity |
| 26 | +- an explicit provider revision value |
| 27 | +- a replay identity used to distinguish new revisions from duplicate deliveries |
| 28 | + |
| 29 | +## Revision Rules |
| 30 | + |
| 31 | +- Keeper must treat the tuple `(provider kind, repository, issue number, |
| 32 | + provider revision)` as the canonical replay identity for the normalized |
| 33 | + request. |
| 34 | +- A provider event that resolves to the same replay identity is a duplicate |
| 35 | + delivery and must not create a second planning mutation. |
| 36 | +- An issue edit that changes the provider revision creates a new normalized |
| 37 | + revision and triggers a fresh Keel evaluation. |
| 38 | +- Re-fetching the same revision is a retry path, not a semantic change. |
| 39 | + |
| 40 | +## Invocation Boundary |
| 41 | + |
| 42 | +Keeper is responsible for: |
| 43 | + |
| 44 | +- polling or receiving GitHub issue changes |
| 45 | +- detecting the mission request activation rule |
| 46 | +- normalizing issue content and provider metadata into the canonical request |
| 47 | +- deciding whether the current event is a new revision or a duplicate retry |
| 48 | +- invoking native `keel mission request` stages |
| 49 | +- delivering provider-facing acknowledgements |
| 50 | + |
| 51 | +Keel is responsible for: |
| 52 | + |
| 53 | +- the canonical request schema |
| 54 | +- validation and diagnostics |
| 55 | +- planning mutation semantics |
| 56 | +- acknowledgement payload rendering |
| 57 | + |
| 58 | +## Acknowledgement Rules |
| 59 | + |
| 60 | +- Acknowledgements must refer to the exact issue identity and revision that |
| 61 | + produced the current Keel outcome. |
| 62 | +- Keeper owns posting or retrying provider-facing acknowledgements. |
| 63 | +- Keel owns rendering the canonical acknowledgement payload from the validated |
| 64 | + request and planning result. |
| 65 | +- A failed acknowledgement retry must not cause Keeper to replay the planning |
| 66 | + mutation when the replay identity is unchanged. |
| 67 | + |
| 68 | +## Failure Modes |
| 69 | + |
| 70 | +| Failure | Classification | Response | |
| 71 | +|---------|----------------|----------| |
| 72 | +| Title/body do not satisfy activation rule | non-request traffic | ignore as ordinary issue activity | |
| 73 | +| Required mission request sections are missing | validation failure | retain issue identity and surface repairable diagnostics | |
| 74 | +| Duplicate delivery for unchanged revision | replay duplicate | reuse the prior normalized result, no new planning mutation | |
| 75 | +| Provider edit races with fetch | revision change | normalize the latest revision and re-evaluate once | |
| 76 | +| Keel rejects a normalized request | execution or validation failure | preserve diagnostics and bind them to the triggering revision | |
| 77 | +| Provider acknowledgement fails after Keel succeeds | transport failure | retry acknowledgement only, not planning mutation | |
0 commit comments