diff --git a/.beads/issues.jsonl b/.beads/issues.jsonl
index 20cf8bfb0..4753c2b56 100644
--- a/.beads/issues.jsonl
+++ b/.beads/issues.jsonl
@@ -560,6 +560,7 @@
 {"_type":"issue","id":"go-hwb.106","title":"S3 Control: ~48 missing ops (access points/grants/batch jobs/MRAP)","description":"## S3 Control — Service Deep Dive\n\nAudit of [services/s3control/](services/s3control/) and UI in [ui/src/routes/s3control/](ui/src/routes/s3control/).\n\n### 1. Missing SDK Operations\n~48 missing ([sdk_completeness_test.go#L21](services/s3control/sdk_completeness_test.go#L21)): `DeleteAccessGrant`, `DeleteBucket`, `GetAccessPoint`, `ListAccessPoints`, `PutAccessPointPolicy`, Access Grants, Access Points, Batch Jobs, MRAP, Storage Lens Group. Only 13 supported (public access block + partial).\n\n### 2. Missing UI / Dashboard Features\nPublic access block display only. Missing: access points mgmt, access grants, batch job UI, MRAP, storage lens groups, Object Lambda.\n\n### 3. Goroutine / Resource / Lock Leaks\nClean. Map cloning on snapshot ([persistence.go#L44](services/s3control/persistence.go#L44)).\n\n### 4. Performance Optimizations\n1. 10+ separate maps — consolidate with typed keys to reduce Reset cost.\n2. Atomic counter for IDs ([backend.go#L178](services/s3control/backend.go#L178)) good.\n\n### Suggested Order\n1. Access Points (Create/Get/List/Put policy)\n2. Access Grants (Create/Delete/List)\n3. Batch Jobs + MRAP + Storage Lens Group\n4. Consolidate map structure\n\n\n---\n**Source:** https://github.com/BlackbirdWorks/gopherstack/issues/1223\n","status":"closed","priority":2,"issue_type":"task","owner":"andrew.bishop9625@gmail.com","created_at":"2026-05-02T18:28:35Z","created_by":"mayor","updated_at":"2026-07-30T16:59:49Z","closed_at":"2026-07-30T16:59:49Z","close_reason":"STALE (parity-5 verification sweep): verified against code, not PARITY.md prose. The authoritative reflective TestSDKCompleteness test passes for this service with an empty notImplemented list, i.e. zero unaccounted SDK operations - refuting the ticket's missing-ops claim. UI route page exists and is substantial. Ticket was auto-generated 2026-05-02, before the parity-3/4/5 campaigns did this work.","external_ref":"gh-1223","labels":["ai-queue"],"dependencies":[{"issue_id":"go-hwb.106","depends_on_id":"go-hwb","type":"parent-child","created_at":"2026-05-02T13:28:35Z","created_by":"mayor","metadata":"{}"}],"dependency_count":0,"dependent_count":0,"comment_count":0}
 {"_type":"issue","id":"go-hwb.102","title":"Timestream Write: SDK complete; per-table WriteRecords locks","description":"## Timestream Write — Service Deep Dive\n\nAudit of [services/timestreamwrite/](services/timestreamwrite/) and shared UI in [ui/src/routes/timestream/](ui/src/routes/timestream/).\n\n### 1. Missing SDK Operations\n**0 missing.** 20 ops implemented including `CreateDatabase`, `CreateTable`, `WriteRecords`, `CreateBatchLoadTask`, `ResumeBatchLoadTask`, tags.\n\n### 2. Missing UI / Dashboard Features\nShared UI covers DBs + tables + scheduled queries. Full CRUD. Batch load UI could be enhanced.\n\n### 3. Goroutine / Resource / Lock Leaks\nClean. 4 nested maps under single `lockmetrics.RWMutex` ([backend.go#L159](services/timestreamwrite/backend.go#L159)).\n\n### 4. Performance Optimizations\n1. **Single mutex serializes WriteRecords across tables** — partition by table-ARN for ~10x throughput.\n2. Dispatch pre-built ([handler.go#L62](services/timestreamwrite/handler.go#L62)).\n\n### Suggested Order\n1. Per-table-ARN partition locks for `WriteRecords`\n2. Batch load UI polish\n\n\n---\n**Source:** https://github.com/BlackbirdWorks/gopherstack/issues/1227\n","status":"closed","priority":2,"issue_type":"task","owner":"andrew.bishop9625@gmail.com","created_at":"2026-05-02T18:28:34Z","created_by":"mayor","updated_at":"2026-07-30T16:59:48Z","closed_at":"2026-07-30T16:59:48Z","close_reason":"STALE (parity-5 verification sweep): verified against code, not PARITY.md prose. The authoritative reflective TestSDKCompleteness test passes for this service with an empty notImplemented list, i.e. zero unaccounted SDK operations - refuting the ticket's missing-ops claim. UI route page exists and is substantial. Ticket was auto-generated 2026-05-02, before the parity-3/4/5 campaigns did this work.","external_ref":"gh-1227","labels":["ai-queue"],"dependencies":[{"issue_id":"go-hwb.102","depends_on_id":"go-hwb","type":"parent-child","created_at":"2026-05-02T13:28:34Z","created_by":"mayor","metadata":"{}"}],"dependency_count":0,"dependent_count":0,"comment_count":0}
 {"_type":"issue","id":"go-hwb","title":"Epic: ai-queue from BlackbirdWorks/gopherstack","description":"Autonomous grinding of GitHub issues labeled 'ai-queue' from BlackbirdWorks/gopherstack. Each child bead corresponds to one GitHub issue (external-ref gh-N). Launched via gt mountain for wave-based dispatch with Witness failure tracking and merge-on-CI-pass via Refinery.","status":"open","priority":2,"issue_type":"epic","owner":"andrew.bishop9625@gmail.com","created_at":"2026-05-02T18:27:46Z","created_by":"mayor","updated_at":"2026-05-02T18:27:46Z","labels":["ai-queue"],"dependency_count":0,"dependent_count":0,"comment_count":0}
+{"_type":"issue","id":"gopherstack-t4ks","title":"amplify: TestListArtifacts_ProducedByJobCompletion is flaky (running job briefly has artifacts)","description":"Failed once in CI on an unrelated PR (#2419, job 95125560578, run 31930944354):\n\n  FAIL: services/amplify TestListArtifacts_ProducedByJobCompletion/running_job_has_no_artifacts_yet\n  Error: Should be empty, but was [0xc0000c0540]\n\nThe subtest asserts a job in RUNNING state has produced no artifacts yet, and found one.\n\nNot caused by that PR: the branch touches zero files under services/amplify (git diff --name-only origin/main...HEAD), the test passes 5/5 locally, and main's last three runs are green. Re-running the job cleared it.\n\nLikely an async race - the job completes and produces its artifact between the test's setup and its assertion, so whether the subtest sees RUNNING-with-no-artifacts depends on scheduling. Look for a background completion goroutine driven by wall-clock time rather than an injected clock. Note this repo bans time.Sleep in tests; the fix is probably testing/synctest or making completion explicitly triggered rather than timed.\n\nLow priority - one observed occurrence - but it will keep costing unrelated PRs a CI cycle until fixed.","status":"open","priority":3,"issue_type":"bug","owner":"blackbird7181@gmail.com","created_at":"2026-08-16T06:44:22Z","created_by":"Witness Patrol","updated_at":"2026-08-16T06:44:22Z","dependency_count":0,"dependent_count":0,"comment_count":0}
 {"_type":"issue","id":"gopherstack-dbvw","title":"dynamodb: UpdateTable exclusivity check is stricter than AWS documents","description":"countUpdateTableMutations (services/dynamodb/table_ops.go) treats eight fields as mutually exclusive. AWS documents only three.\n\nThe SDK's own UpdateTable doc (api_op_UpdateTable.go:17-24, aws-sdk-go-v2/service/dynamodb v1.63.1) says verbatim:\n\n  You can only perform one of the following operations at once:\n    - Modify the provisioned throughput settings of the table.\n    - Remove a global secondary index from the table.\n    - Create a new global secondary index on the table.\n\nNot listed, but treated as exclusive by our check: ReplicaUpdates, SSESpecification, StreamSpecification, DeletionProtectionEnabled, TableClass. A client that legitimately combines any of these with a throughput change gets a 400 from us and a success from real AWS.\n\nThis is the same class of bug just fixed for BillingMode, which our check also treated as exclusive even though AWS REQUIRES it alongside ProvisionedThroughput when switching modes ('When switching from pay-per-request to provisioned capacity, initial provisioned capacity values must be set', api_op_UpdateTable.go:60-63). That one was found only because terraform-provider-aws sends billing_mode on every capacity change and the terraform drift suite went red.\n\nThe BillingMode half is fixed. The remaining five are untested and unexercised - no client in our suites currently combines them - so this is latent, not observed. Verify each against the SDK before loosening; do not bulk-delete the check.","status":"open","priority":3,"issue_type":"bug","owner":"blackbird7181@gmail.com","created_at":"2026-08-15T17:00:41Z","created_by":"Witness Patrol","updated_at":"2026-08-15T17:00:41Z","dependency_count":0,"dependent_count":0,"comment_count":0}
 {"_type":"issue","id":"gopherstack-c1g8","title":"codeql (go) / Analyze (go) never reports on this repo","description":"Across four CI runs on chore/queue-2026-08-11, the 'codeql (go)' and 'Analyze (go)' checks have never reported a status. Analyze (javascript-typescript) runs and passes.\n\nConsequence: there is currently NO Go static-analysis coverage in CI, and a request to 'fix any codeql issues' is unanswerable for Go because no Go findings are ever produced. Silent absence reads as 'clean' - that is the dangerous part.\n\nInvestigate: is the Go matrix leg failing to start, filtered by a path filter, or timing out on a 162-service module? Check .github/workflows for the CodeQL config.","status":"open","priority":3,"issue_type":"bug","owner":"blackbird7181@gmail.com","created_at":"2026-08-15T16:16:57Z","created_by":"Witness Patrol","updated_at":"2026-08-15T16:29:04Z","dependencies":[{"issue_id":"gopherstack-c1g8","depends_on_id":"gopherstack-m8mg","type":"blocks","created_at":"2026-08-15T11:29:06Z","created_by":"Witness Patrol","metadata":"{}"}],"comments":[{"id":"01a00641-6b91-70cc-b872-a63241d5462b","issue_id":"gopherstack-c1g8","author":"Witness Patrol","text":"CORRECTION — the premise of this issue as filed is WRONG. I filed it, and I was wrong on three counts.\n\n1. \"codeql (go) never reports\" — false. Verified: run 31893253913, job codeql (go), conclusion SUCCESS, 15:38:09Z -\u003e 15:57:37Z (19m28s).\n2. \"No Go static-analysis coverage in CI\" — false. code-scanning/analyses shows /language:go SARIF uploads landing continuously against refs/pull/2417/merge, most recently 16:19:19Z and 16:16:44Z on 2026-08-15.\n3. \"The prior standalone-CodeQL issue is closed\" — false. gopherstack-m8mg is OPEN, P3, filed 2026-07-11, never actioned.\n\nWHAT IS ACTUALLY HAPPENING: ci.yml's codeql job (lines 135-162) takes ~19.5 minutes and lives in a workflow with concurrency.cancel-in-progress: true. During rapid iteration this branch was receiving pushes every 3-7 minutes, so nearly every codeql (go) run was CANCELLED before finishing. Adjacent runs 31895063602 and 31894903224 both show conclusion=cancelled. Sampling four consecutive runs mid-iteration caught it cancelled every time, which is indistinguishable from \"never reports\" if you do not look at the conclusion field.\n\nMy own push cadence was cancelling the check I was reporting as missing.\n\nMeanwhile Analyze (go) / Analyze (javascript-typescript) come from a SECOND, GitHub-managed default-setup workflow (event: dynamic, workflowName: CodeQL, no file in the repo). It is not subject to ci.yml's concurrency policy, so it completes reliably. That is the duplication gopherstack-m8mg is about.\n\nOPEN CODEQL ALERTS: zero. The single open code-scanning alert is #246, tool=Scorecard, rule=Vulnerabilities — not CodeQL. Go CodeQL has produced real findings historically (dismissed alert 254, cognitoidp SRP, tracked in gopherstack-ylyb).\n\nREDUCED TO P3 and re-scoped: this is not \"Go analysis is missing\". It is the same repo-settings duplication as gopherstack-m8mg, plus a real but lesser annoyance — a 19.5-minute job under cancel-in-progress will almost never complete on an actively-pushed branch, so it burns runner time and yields a cancelled required check. Options: drop ci.yml's codeql job in favour of default setup, disable default setup in repo settings, or move the codeql job to its own workflow without cancel-in-progress. Repo-settings/config decision, not agent-fixable.\n\nOne unresolved discrepancy, flagged rather than smoothed over: gh api code-scanning/default-setup returns {\"state\":\"not-configured\"}, which contradicts the live evidence of a default-setup workflow running. Most likely the token lacks the scope and returns a placeholder. Not verified either way.","created_at":"2026-08-15T16:29:06Z"}],"dependency_count":1,"dependent_count":0,"comment_count":1}
 {"_type":"issue","id":"gopherstack-t0gq","title":"resume or discard the stashed directoryservice and opsworks sweeps","description":"Two 6flj passes were killed mid-edit by an API session limit on 2026-08-15. Their work is in a git stash, message 'wip: killed by session limit'.\n\nSTATE, verified before stashing:\n- services/directoryservice does NOT compile. It was mid-refactor, splitting handleDeleteADAssessment off a shared two-field handler, with an unused context import left behind. Roughly 18 files touched.\n- services/opsworks builds but FAILS its tests - TestElasticIps/RegisterElasticIp_without_StackId_returns_400 got 200. Ten files plus a new opsworks SDK dependency in go.mod. The agent's last words were that it was about to verify each fix against unfixed code, so nothing had been hand-reverted yet.\n\nNeither meets this campaign's bar: every fix hand-reverted individually and confirmed to fail with the predicted symptom. Both were stashed rather than committed, and rather than discarded, because the findings themselves may be real.\n\nTHE OPSWORKS FAILURE IS AMBIGUOUS and that is the reason to look rather than assume. A test expecting 400 and getting 200 is either the agent breaking an existing test, or a NEW test correctly failing because it had just found a missing validation and had not yet fixed it. Those are opposite conclusions and telling them apart needs the diff read.\n\nRECOMMENDED: do not resume from the stash. Re-sweep both services fresh, and use the stash only as a hint about where to look. Resuming someone else's half-finished refactor is worse than starting clean, and the remainder file already treats both as unswept so nothing is lost by redoing them.\n\nDrop the stash once that judgement is made either way - a stale stash is worse than none.","status":"closed","priority":3,"issue_type":"task","owner":"blackbird7181@gmail.com","created_at":"2026-08-15T09:51:43Z","created_by":"Witness Patrol","updated_at":"2026-08-15T10:49:13Z","closed_at":"2026-08-15T10:49:13Z","close_reason":"Both services re-swept fresh. The stash can be dropped.\n\nopsworks: 4 bugs fixed and committed in 0f5a7d360. directoryservice: 6 bugs fixed and committed in 78517e30d.\n\nTHE AMBIGUOUS TEST IS RESOLVED, and it was the favourable reading.\nRegisterElasticIp_without_StackId_returns_400 does NOT exist at HEAD, so the killed session had written a NEW test that correctly failed on a validation gap it had found and not yet fixed - it had not broken a pre-existing test. Settled by grepping HEAD rather than inferring. The underlying bug is real: RegisterElasticIpInput declares ElasticIp and StackId required and has no Region member, while gopherstack accepted a fabricated Region and never checked StackId.\n\nBOTH RE-SWEEPS WERE DONE FRESH, with the stash read read-only as a hint only. That was the right call. For directoryservice, five of the stash's hints pointed at real bugs but all were independently re-derived, and one bug - DescribeSettings emitting the request-side filter name Status where the real member is RequestStatus - was found this pass and is NOT in the stash. Resuming would have inherited an uncompilable mid-refactor and still missed that.\n\nThe dependency boundary the stash had crossed was also restored: it had added the opsworks SDK to go.mod. The fresh pass confirmed the module is in the cache but absent from go.mod, cited the cached source for every wire claim, and disclosed a 0-of-74 real-client test ratio rather than taking the dependency to make its tests easier.\n\nNothing in the stash is needed. Drop stash@{0} whenever convenient - it is now purely a record of an interrupted session.","comments":[{"id":"01a00500-0211-7441-a900-5bb3d9e80e13","issue_id":"gopherstack-t0gq","author":"Witness Patrol","text":"opsworks half RESOLVED this session (2026-08-15), directoryservice half still\nopen (live sibling working it separately).\n\nVERDICT on the ambiguous test: (b), not (a). RegisterElasticIp_without_StackId_returns_400\nwas a NEW test, not a pre-existing one broken by the killed session --\nconfirmed via `git show HEAD:services/opsworks/elastic_ips_test.go | grep\nStackId` (zero hits at HEAD). It correctly caught a real gap: the real\nRegisterElasticIpInput has ElasticIp and StackId both \"This member is\nrequired\" and no Region member at all (confirmed against\naws-sdk-go-v2/service/opsworks@v1.31.0's api_op_RegisterElasticIp.go, read\nfrom the module cache -- not a go.mod dependency, present in GOMODCACHE\nonly). The killed session's stashed code added StackId as a parameter but\nnever validated it was non-empty, so its own new test correctly failed with\n200 instead of 400.\n\nopsworks was swept fresh (not resumed from the stash, per this issue's own\nrecommendation), independently re-deriving and re-verifying every finding\nagainst the real SDK. 4 real bugs fixed total (RegisterElasticIp's missing\nStackId validation + fabricated Region field, DescribeElasticIps' discarded\nStackId filter, DescribeElasticLoadBalancers' discarded LayerIds filter,\nDescribeStackProvisioningParameters' fabricated Parameters.AgentInstallerUrl\nduplicate key). Full detail in gopherstack-6flj's latest comment and\nservices/opsworks/PARITY.md's \"gopherstack-6flj wrapper-key sweep\n(2026-08-15)\" section. stash@{0} was read read-only throughout and was never\npopped/applied/dropped -- still present, holding only the directoryservice\nhalf now that opsworks is done. Safe to drop the opsworks portion's\nrelevance to this issue; leave the stash itself alone until directoryservice\nis also resolved, since it's a single combined stash entry for both\nservices.\n","created_at":"2026-08-15T10:38:02Z"}],"dependency_count":0,"dependent_count":0,"comment_count":1}