[AbirAbbas]

What this fixes

• A keyed job create that wrote nothing runs again; one that wrote something is replayed. The Factory's idempotency cache replayed the first answer under an Idempotency-Key for 24 hours. That included server errors and refusals given before anything was written, so a resend after a transient failure, or after the person fixed a refusal, could never succeed. A job create (POST /v1/jobs, POST /v1/issues) now starts with the X-Codeaf-Phase: pre-mutation marker and clears it just before its first write: the GitHub issue request once it has a connection, and the job's own make. An answer still marked is not kept, so the same key runs the create again. An answer given after that, a 5xx or 408 included, is replayed, so a resend does not make a second job or issue. Rows an older build stored carry no marker and are replayed. Worker and runner routes keep their rule: a 5xx, 408 or 429 is never kept. Two limits remain. The row is keyed by the exact Authorization and Cookie, so a resend under a new bearer or session cookie runs as a new create. And it is saved only after the create commits, so a Factory that stops in between runs the resend again.
• The Factory says so. GET /v1/features (factory.features) lists keyed_create, with or without a store. An engine can then tell this Factory from an older one, which keeps every keyed answer for 24 hours, refusals and server errors included, and send a create key only here. factory.job_create: issue choice, labels, starting budget, retry key, split_from; factory.job_context_set #2617 does exactly that.
• A rate-limited source poll says so. TroubleWords reads "rate limited" for any GitHub 429 and for a 403 that carries a retry time; a 403 without one still reads "not reachable".

Where it comes from

This carries the poll words of #2439 and #2460, which merged only into workstreams/main. It replaces #2439's keyed-replay rule: #2439 stopped keeping every 5xx, 408 and 429, so a create that failed after making its job or issue ran again and made a second one. That branch's integration PR (#2306) is closed and will not merge. The visibility-check halves of both are in #2618, because they answer in the repository issues read's shape.

Both faults are still on dev. With only the tests brought over:

--- FAIL: TestAKeyedCreateThatWroteNothingRunsAgain
    keyed_create_test.go:305: resend after the cause passed = 502 {..."error":"GitHub isn't answering; retry this job change"...}
    keyed_create_test.go:305: resend after the cause passed = 422 {..."error":"pipeline not found"...}
--- FAIL: TestAKeyedServerErrorRunsAgainOnRetry
    idempotency_transient_test.go:130: attempt 0 = 503 "retry this answer", header="retry this answer" phase="" calls=1; want 503 "retry this answer" phase="pre-mutation" calls=1
--- FAIL: TestTheFactorySaysItRunsAKeyedCreateThatWroteNothingAgain
    keyed_create_feature_test.go:31: features = [group_policy waits_on], want "keyed_create" listed
--- FAIL: TestTroubleWordsNameASpentRateLimit
    poll_limit_test.go:32: trouble words = "not reachable", want "rate limited"

TestAKeyedCreateAnsweredAfterItsWriteIsReplayed passes on dev, because dev keeps every answer. It fails on #2439's rule, which made a second issue or job.

Tests

Locally (macOS), on this head (c937532):

• go test -count=1 -p 2 ./internal/factory/serve/ ./internal/factory/api/: both ok (internal/factory/serve in 58.7s).
• In cmd/codeaf, by name with -p 2: TestADeskGoAheadStartsTheCoveredJobAfterItsParentMerges and the four TestAppFactoryJobAction* tests: ok.
• make test-quick: exit 0.
• make changelog-check: 795 entries, all well formed.
• make test-packed-manual manual-gates: exit 0.
• internal/factory/github (the poll words) is unchanged since 3489017, where make pr-ready ran it fresh: ok in 40.2s. That run kept gh off PATH: on this Mac TestAHangingGHNeverHoldsTheReadsThatAskForTheToken fails on a clean origin/dev too when the real gh is on PATH (a gh that answers at once: "" via ""). It is not touched by this change.

Merged with #2617 (f0996a4) on dev 6616e85, in a throwaway worktree: go build ./... ok; internal/factory/serve, api, run, store and internal/appwire ok; 41 named cmd/codeaf tests pass. One of them was a throwaway end-to-end test: the real merged Factory gets create_key and the key, a pre-write 501 under the key runs again, and then the same key replays one job. The same server answering features as an older Factory does gets create_key: false, a keyed create answers factory_too_old, and the older Factory never sees the key. make test-packed-manual manual-gates, make changelog-check (803 entries) and make test-quick exit 0.

CI on this head (c937532): check, light gate, touched codeaf, touched rest, touched session, touched tui3, touched packages and windows native tests pass.

Changes after review

Round 1. The first version carried #2439's rule as it was: no 5xx, 408 or 429 answer under a key was kept. Review found that a job create can fail after it has made its GitHub issue or its job: a lost GitHub answer, a failed store write, a failed start. The same-key resend then ran again and made a second issue or job. The fix (9b590fe) reuses the Factory's existing X-Codeaf-Phase: pre-mutation marker. POST /v1/jobs and POST /v1/issues start marked. newJob clears the marker just before seam.New or seam.NewJob, and the GitHub issue request clears it once GitHub may have acted: a failure after the request got a connection, or any answer but GitHub's own 4xx refusal. Only a marked answer is not kept. The in-memory capture had dropped the marker the handler cleared, so a keyed answer always looked pre-write; it now copies it, and a replay never claims nothing was written. Worker and runner routes keep dev's rule. The PROTOCOL paragraph, a new manual section and the change entry describe the rule.

Pass 2. Review then found three more things.

• With factory.job_create: issue choice, labels, starting budget, retry key, split_from; factory.job_context_set #2617, the engine sent a fixed per-draft key to Factories of any age. A Factory older than this PR keeps every keyed answer, refusals included, so a draft refused as too old got the same refusal back for 24 hours, even after the Factory was updated, because the old row carries no marker. Rather than guess which old rows to drop, the Factory now announces the rule: GET /v1/features lists keyed_create (new api.FeatureKeyedCreate, 878ecd9). factory.job_create: issue choice, labels, starting budget, retry key, split_from; factory.job_context_set #2617 sends a key only to a Factory that lists it, so no engine sends a key to a Factory that would keep a pre-write answer. internal/factory/api/keyed_create.go is the same file byte for byte on factory.job_create: issue choice, labels, starting budget, retry key, split_from; factory.job_context_set #2617, so the two merge in either order.
• TestKeyedSuccessAndRefusalsStillReplay claimed that a /v1/jobs refusal replays for 24 hours. It passed only because it skipped the route's marker; a real create refusal is marked and not kept. It is replaced by TestAKeptKeyedAnswerReplaysForADay, which goes through the marker and covers a create's success and an unmarked verb's 422 and 409, in memory and on disk. A create refusal the person fixed now runs again on the real handler (TestAKeyedCreateThatWroteNothingRunsAgain/a_job_create_refusal_the_person_fixed). The marker clear before seam.NewJob is now proven too: a new case makes the job through NewJob, and it fails when that clear is deleted (0a97315).
• The docs said a same-key resend never makes a second job or issue. They now state the two limits the code has: the exact Authorization and Cookie in the row's key, and the row saved only after the create commits (c937532).

The title and this description were rewritten to match.

🤖 Generated with Claude Code