instar 1.3.1313 → 1.3.1315

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "instar",
-  "version": "1.3.1313",
+  "version": "1.3.1315",
   "description": "Coherence infrastructure for self-evolving AI agents — on the Claude Code or Codex subscription you already have.",
   "type": "module",
   "main": "dist/index.js",

package/src/data/builtin-manifest.json

@@ -1,8 +1,8 @@
 {
   "$schema": "./builtin-manifest.schema.json",
   "schemaVersion": 1,
-  "generatedAt": "2026-10-02T01:51:41.995Z",
-  "instarVersion": "1.3.1313",
+  "generatedAt": "2026-10-02T10:55:24.335Z",
+  "instarVersion": "1.3.1315",
   "entryCount": 203,
   "entries": {
     "hook:session-start": {
@@ -1539,7 +1539,7 @@
       "type": "subsystem",
       "domain": "server",
       "sourcePath": "src/server/AgentServer.ts",
-      "contentHash": "1f54e9359f0c4604ad4b9d5e8420f7be0a33907c000ae5e1ac957c82d4ef9434",
+      "contentHash": "015d93053813a521d0f06087f9bea72a07bd76cc7ca424d584ffd9ea06e76508",
       "since": "2025-01-01"
     },
     "subsystem:session-manager": {

package/src/data/standards-guard-index.json

@@ -2,7 +2,7 @@
   "schemaVersion": 1,
   "generatedFrom": "source-tree",
   "registrySha256": "35448db940d659661ebdfb09761439033f93a15157540ee2f6eecf825488e1e6",
-  "packageVersion": "1.3.1313",
+  "packageVersion": "1.3.1315",
   "guards": [
     {
       "ref": "docs/audits/phase-b/f10-triage.md",

package/src/data/standards-guard-index.meta.json

@@ -1,5 +1,5 @@
 {
-  "sha256": "8ce42dd4c6abeb23b4d5187b6de490f3f39b33ca878b15d820aa4f1822315c16",
+  "sha256": "81bd9fa3c78c88ad9c840e55c57dda4d4c4566f3fea67f8defd03cf97099e00f",
   "registrySha256": "35448db940d659661ebdfb09761439033f93a15157540ee2f6eecf825488e1e6",
-  "packageVersion": "1.3.1313"
+  "packageVersion": "1.3.1315"
 }

package/src/data/standards-registry.meta.json

@@ -2,5 +2,5 @@
   "sha256": "35448db940d659661ebdfb09761439033f93a15157540ee2f6eecf825488e1e6",
   "articleCount": 92,
   "generatedFrom": "docs/STANDARDS-REGISTRY.md",
-  "packageVersion": "1.3.1313"
+  "packageVersion": "1.3.1315"
 }

package/src/scaffold/templates/jobs/instar/feedback-factory-process.md

@@ -3,7 +3,7 @@ name: Feedback-Factory Operating Drain
 description: "Cadenced end-to-end feedback drain. POST /feedback-factory/drain/tick clusters canonical input, runs registered frontier-model readiness judgment inside deterministic floors, enqueues one durable outbox row per readiness epoch, and—after separate consumer promotion—creates and reads back one Initiative task. Development-agent processing/drain is live; fleet remains dark; consumer ships simulation-first. Spec: docs/specs/feedback-factory-operating-drain.md."
 schedule: "*/30 * * * *"
 priority: low
-expectedDurationMinutes: 2
+expectedDurationMinutes: 5
 model: haiku
 supervision: tier1
 enabled: true
@@ -36,7 +36,8 @@ TOKEN = os.environ.get('INSTAR_AUTH_TOKEN') or (CONFIG.get('authToken') if isins
 AGENT_ID = os.environ.get('INSTAR_AGENT_ID') or str(CONFIG.get('projectName') or '')
 BASE = 'http://localhost:' + str(os.environ.get('INSTAR_PORT') or CONFIG.get('port') or 4042)
 DEVELOPMENT_AGENT = CONFIG.get('developmentAgent') is True
-POLL_SECONDS = float(os.environ.get('FEEDBACK_DRAIN_POLL_SECONDS') or 60)
+# A run is capped at 115 s of wall clock; poll past that so a slow run's outcome is still read here.
+POLL_SECONDS = float(os.environ.get('FEEDBACK_DRAIN_POLL_SECONDS') or 180)
 
 def fail(reason):
     path = os.environ.get('INSTAR_JOB_FAILURE_FILE')
@@ -103,7 +104,9 @@ run_id = tick['runId']
 if tick.get('proxied'):
     done('proxied to the owner machine, run ' + run_id + '; the owner records its outcome')
 
-# 3. Poll this run to a terminal state (60 s). Still running at the limit is not a failure.
+# 3. Poll this run to a terminal state. Still running past the drain's wall clock is a failed run:
+# no later cadence reads this run's outcome (live 2026-10-01: two degraded 70 s runs were recorded
+# as successes by a 60 s poll).
 deadline = time.time() + POLL_SECONDS
 last = None
 after = None
@@ -114,7 +117,8 @@ while time.time() < deadline:
         break
     time.sleep(3)
 else:
-    done('run ' + run_id + ' still in flight; the next cadence observes it')
+    seen = (str(last.get('runId')) + ' ' + str(last.get('state'))) if isinstance(last, dict) else 'no lastRun (HTTP ' + str(code) + ')'
+    fail('drain run ' + run_id + ' still in flight after ' + str(int(POLL_SECONDS)) + ' s, past the drain wall clock (last seen: ' + seen + ')')
 
 # 4. Tier-1 supervision of the terminal run.
 run_state = last.get('state')
@@ -131,7 +135,7 @@ The script prints one `FEEDBACK_DRAIN_RESULT` line. It records a failed run itse
 - Posture `dark` → silent exit. `unavailable` → failed run. Unreadable status → failed run on a development agent, silent exit on the fleet.
 - A refused tick (any HTTP code other than 202, e.g. `current registered readiness agent required` after the authority was demoted) → failed run.
 - A tick proxied to the owner machine → success here; its outcome lives in the owner's run history and status.
-- Terminal `succeeded` / `no-op` → success. Terminal `degraded`, `failed` or `abandoned` → failed run carrying the drain's reason.
+- Terminal `succeeded` / `no-op` → success (a `succeeded` run may carry an informational reason such as `readiness-time-exhausted-rest-due`). Still in flight after 180 s → failed run. Terminal `degraded`, `failed` or `abandoned` → failed run carrying the drain's reason.
 - In simulation, claimed/completed work counts must not advance; if they do → failed run.
 
 Never retry in the same run; the durable queue and the next cadence own retry. Then exit silently. Do NOT relay anything to Telegram and do NOT summarize. A failed run reaches the operator through the scheduler's consecutive-failure alert.

package/upgrades/1.3.1314.md

@@ -0,0 +1,52 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+The feedback drain's readiness stage sent all due clusters, up to the authority's
+`maxBatch`, to the registered model in one call. Live, at about 3-4 s per candidate, a
+50-candidate call hit the 60 s call budget every time, and the run degraded with
+`readiness-authority-failed`.
+
+- A tick now reviews its due clusters in sequential calls of at most
+  `feedbackFactory.drain.readinessChunkSize` (default 10). The total per tick is still capped
+  at the authority's `maxBatch`.
+- Later calls are sized from the pace measured earlier in the same tick, so the last call
+  still fits the tick's wall clock. 20 s is kept for the stages after readiness. Rows not
+  reached stay due for the next tick.
+- Each call's decisions apply as it returns. A later failure no longer discards them.
+- Spend is reserved per call, against the same daily cap.
+- A contract violation still demotes the authority at once. A tick with any successful call
+  resets the transient-failure count. A tick in which every call failed counts once (3 in a
+  row demote).
+- `feedbackFactory.drain.maxWallClockMs` is now honoured. It was declared (90 s, as the spec
+  says) but ignored, so the service ran on 115 s.
+
+Prompt and schema versions are unchanged, so the registered authority stays valid.
+
+## What to Tell Your User
+
+The feedback sorter was asking its model about too many feedback groups at once, and the
+model ran out of time every time. It now asks about ten at a time and keeps going while time
+allows. Earlier answers are kept even if a later question fails. Nothing for you to do.
+
+## Summary of New Capabilities
+
+- The feedback drain reviews readiness in time-bounded chunks (`feedbackFactory.drain.readinessChunkSize`, default 10).
+
+## Evidence
+
+From the Mac Studio's live store (a read-only copy):
+- Runs 2b4bebb3 and 0e7b229a: 50 candidates, 60.1 s each, both timeouts.
+- Run 20c4fac7: 10 candidates, 32.6 s, succeeded.
+
+Tests replay the recorded gpt-6-astra replies with that latency shape:
+- At a 90 s tick, the calls are 10, 10 and 2 (22 clusters decided).
+- A timeout on the second call keeps the first call's 5 `ready` decisions and resets the
+  failure count.
+- The old single 50-candidate call times out.
+
+Unit (11), integration (2) and e2e (1) cover this. Of the original 11, 10 fail on the pre-fix
+source; the 11th guards the unchanged demotion rule.

package/upgrades/1.3.1315.md

@@ -0,0 +1,51 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+Two live faults on 2026-10-01 (Mac Studio, v1.3.1314, authority gen 4 with `maxBatch` 50):
+
+- **A good tick was labelled degraded.** Runs ef0f6cbf and 10674e04 each made two good
+  readiness calls (about 20 and 17 decisions applied, zero provider errors). Then each started
+  a one-candidate call with under 8 s left. A call also pays about 9 s of start-up that the
+  per-candidate pace does not show, so the drain's own tick clock cut it at 70.0 s, and the
+  run ended `degraded` / `readiness-authority-failed`.
+  - A call after the first now needs at least 25 s left (`MIN_LATER_READINESS_CALL_MS`).
+  - If the tick clock (not the provider) cuts a later call short, its rows stay due,
+    untouched.
+  - Either way, a tick that already reviewed some candidates ends `succeeded`. It carries
+    the note `readiness-time-exhausted-rest-due` in the run's reason.
+  - Real failures stay degraded: a provider timeout or error, a contract violation, the
+    spend brake, or a first call that cannot finish.
+- **The job recorded those degraded runs as successes.** The `feedback-factory-process` body
+  polled for 60 s, the runs took 70 s, and it exited "still in flight; the next cadence
+  observes it". No later cadence ever reads an earlier run. It now polls for 180 s, which is
+  above the drain's 115 s wall-clock ceiling. A run still in flight after that fails the job.
+  `expectedDurationMinutes` goes from 2 to 5. Existing agents get the new body and manifest
+  through `installBuiltinJobs` on update. The scheduler's declared-failure file was already
+  wired correctly.
+
+## What to Tell Your User
+
+The feedback sorter sometimes ran out of time near the end of a run and wrongly called the
+whole run a failure, even though every answer it got was fine. It now just stops and leaves
+the rest for the next run. Its scheduled job also waits long enough to see how a slower run
+ended, so real failures show up as failures. Nothing for you to do.
+
+## Summary of New Capabilities
+
+- Drain runs that stop for lack of tick time end `succeeded`, with the note `readiness-time-exhausted-rest-due`.
+
+## Evidence
+
+- Live store (read-only `.backup` copy): both runs' readiness rows were stamped at about 32 s,
+  62 s and 70.0 s. The single 70.0 s row in each run was marked `readiness-authority-failed`.
+- The job transcripts read `FEEDBACK_DRAIN_RESULT run run:ef0f6cbf… still in flight` and
+  `… run:10674e04… still in flight`.
+- Unit, integration and e2e tests use the live latency shape (a fixed start-up cost plus a
+  per-candidate pace). The e2e runs the shipped job script against the production
+  AgentServer. On the pre-fix source the calls are `[5, 4, 1]` and the run is degraded. After
+  the fix the calls are `[5, 4]`, the run succeeded with the note, the rest stays due, and the
+  job records success.

package/upgrades/feedback-arbiter-chunking.eli16.md

@@ -0,0 +1,35 @@
+# ELI16 — the feedback sorter asks about ten groups at a time
+
+## The problem
+
+The feedback sorter ("drain") groups similar bug reports. Then it asks a model which groups
+are ready to become a task. It used to put up to 50 groups into one question.
+
+The model takes about 3 to 4 seconds per group. Fifty groups need about three minutes, but
+each question is allowed one minute. So the big question ran out of time every time. The
+run failed and no group got a verdict. With ten groups per question, the answer came back
+in about half a minute.
+
+## The fix
+
+The sorter now asks about at most ten groups per question, one question after another. It
+keeps going until it reaches the run's group limit or runs low on time. Each answer is saved
+as soon as it arrives. If a later question fails, the earlier answers still count.
+
+Before each question it checks the clock. If the next question would not finish in time, it
+stops and leaves the remaining groups for the next run. That run starts with them.
+
+The rule for "the model is broken, stop trusting it" counts whole runs:
+- A run where at least one question worked shows the model is fine, and resets the count.
+- A run where every question failed counts once.
+- Three such runs in a row switch the model off.
+- A wrong-shaped answer still switches it off at once.
+
+A setting for the run's time limit (90 seconds) existed but was never used. The sorter
+quietly used 115 seconds. It now follows the setting.
+
+## What does not change
+
+The question wording, the answer format, the daily spending cap and the approved group
+limit are the same. The spending cap is now checked before each question rather than once
+per run.

package/upgrades/feedback-drain-degraded-label.eli16.md

@@ -0,0 +1,36 @@
+# ELI16 — "ran out of time" is not "broken", and the job now waits for the answer
+
+## The problem
+
+The feedback sorter ("drain") asks a model which groups of bug reports are ready to become a
+task. It asks about up to ten groups per question, one question after another, until its
+run's time is nearly used up.
+
+It guessed how long the next question would take from how long earlier questions took per
+group. But every question also has a fixed start-up cost of about 9 seconds, however few
+groups it holds. Near the end of a run, the sorter had about 8 seconds left. It decided one
+group would fit and asked. The question could never finish in 8 seconds, so its own timer cut
+it off. The run was then labelled "degraded, the model failed", even though the model never
+failed once. Two real runs on 2026-10-01 went exactly like this.
+
+A second fault hid it. The scheduled job that starts each run waited only 60 seconds for the
+result. These runs took 70 seconds, so the job gave up, said "still running, the next run will
+check", and recorded a success. No later run ever checks an earlier one.
+
+## The fix
+
+- The sorter does not start another question unless at least 25 seconds are left.
+- If its own timer still cuts a later question short, that is "out of time", not "the model
+  failed". Those groups simply wait for the next run.
+- A run that got some answers and then ran out of time is now "succeeded". It carries a short
+  note saying the rest is still waiting.
+- Real problems still mark the run degraded: the model timing out on its own, an error, a
+  wrong-shaped answer, the spending cap, or a first question that cannot finish.
+- The job now waits up to 3 minutes. That is longer than any run may last (at most 115
+  seconds). If a run is somehow still going after that, the job counts it as a failure
+  instead of quietly passing.
+
+## What does not change
+
+The question wording, the answer format, the spending cap, the approved group limit and the
+rules for switching the model off all stay the same.

package/upgrades/side-effects/feedback-arbiter-chunking.md

@@ -0,0 +1,224 @@
+# Side-Effects Review — feedback readiness reviewed in chunks
+
+**Version / slug:** `feedback-arbiter-chunking`
+**Date:** `2026-10-01`
+**Author:** `Echo`
+**Second-pass reviewer:** `independent reviewer subagent (see below)`
+
+## Summary of the change
+
+The operated feedback drain asks the registered readiness authority (gpt-6-astra via
+codex-cli) which clusters are ready to become work. It sent every due candidate, up to the
+authority's `maxBatch` (50), in ONE model call. Live on 2026-10-01 the model took about 3-4 s
+per candidate: 10 candidates finished in ~31 s (run 20c4fac7, 32.6 s end to end) and 50 hit
+the 60 s call budget twice in a row (runs 2b4bebb3 and 0e7b229a, 60.1 s each, both
+`readiness-authority-failed`). A 50-candidate call can never fit the call budget.
+
+`FeedbackDrainService` now reviews a tick's due candidates (still capped at the authority's
+`maxBatch`) in sequential calls of at most `readinessChunkSize` (default 10). Before each call
+it checks the time left for readiness (the tick's wall clock minus one 20 s stage budget kept
+for the stages after readiness). The first call is a full chunk; later calls are sized from
+the pace observed so far in that tick, with a 25% margin. Each call's budget is also capped by
+the time left. When the next call would not fit, the loop stops cleanly: rows not reached stay
+due, untouched, for the next tick. Each call's decisions are applied as soon as it returns. A
+failed call stops the tick, and its own rows are marked `readiness-authority-failed`
+(re-review in 15 min). Spend is reserved per call: one `estimatedReadinessBatchUsd` per call,
+plus that call's decision count. Daily usage is still counted per decision.
+
+Failure accounting: a contract violation (wrong model, schema, ids) still demotes the authority
+at once in any call. A transient failure (timeout, provider error) counts ONE toward the
+consecutive-failure limit only if no call in that tick succeeded. A tick with at least one
+successful call resets the counter.
+
+Also: `feedbackFactory.drain.maxWallClockMs` (90 s in config defaults, and 90 s in the approved
+spec §203) was declared but never passed to the service. The service ran on its own 115 s
+default. It is wired now, together with the new optional `readinessChunkSize`.
+
+Files: `src/feedback-factory/drain/FeedbackDrainService.ts`, `src/server/AgentServer.ts`
+(wiring), `src/core/types.ts` (config type). Prompt id, schema id, parser and
+`FeedbackReadinessArbiter` are unchanged.
+
+## Decision-point inventory
+
+- `FeedbackReadinessArbiter.decideBatch` (`feedback-cluster-readiness`): pass-through. The
+  same prompt and schema now receive packets of at most 10 candidates instead of up to 50.
+  Every packet stays inside the registered `maxBatch` envelope.
+- Authority transient-failure demotion (`FeedbackDrainService`): modify. The counter is now
+  per tick (any successful call resets it; an all-failed tick counts once) instead of per
+  single call.
+- Spend brake (`reserveAuthoritySpend`): modify (granularity only). It is reserved per call
+  instead of per tick. The same cap applies, and a brake mid-tick keeps the earlier calls'
+  decisions.
+
+---
+
+## 1. Over-block
+
+No block/allow surface on user content. The one gating effect is on throughput: a tick can
+now review fewer candidates than `maxBatch` when the wall clock runs short. Those rows are
+not rejected; they stay due and the next tick reviews them first (the due order is
+`next_review_at, cluster_id`).
+
+---
+
+## 2. Under-block
+
+- A chunk that keeps timing out after one healthy chunk in every tick never reaches the
+  demotion limit. This is intentional: the tick is making progress. Each such tick still ends
+  `degraded` with `readiness-authority-failed`, and the job reports it as failed, so the
+  pattern stays visible.
+- The per-candidate pace comes from earlier calls in the same tick. A sudden slowdown on a
+  later call can still overrun its slot. That call's budget is capped at the time left, so it
+  fails as a transient failure rather than blowing the tick's wall clock.
+
+---
+
+## 3. Level-of-abstraction fit
+
+This is the right layer. Batching is a drain-service concern: the service owns the tick
+budget, the spend reservation and the failure accounting. The arbiter stays a single-call
+authority adapter with its unchanged envelope check (`candidates.length <= maxBatch`). No
+parallel gate is introduced.
+
+---
+
+## 4. Signal vs authority compliance
+
+- [x] No — this change has no block/allow surface.
+
+The readiness judgment stays with the registered LLM authority. This change only decides how
+many candidates go into each call and when to stop for the tick's time budget. Those are
+resource limits, not judgments about the content.
+
+---
+
+## 4b. Judgment-point check (Judgment Within Floors standard)
+
+No new static heuristic at a competing-signals decision point. Chunk sizing is a resource
+bound over a measured pace (time left / observed per-candidate latency). The readiness
+decision itself remains the LLM authority's.
+
+---
+
+## 5. Interactions
+
+- Cancellation and ownership: `stopIfCancelled()` (owner fence, wall-clock assert, run-lease
+  heartbeat) runs after every call. A long tick therefore heartbeats its 120 s run lease after
+  each call, not only once.
+- Later stages: readiness ends at least one 20 s stage budget before the tick's wall clock.
+  This guarantees each later stage its own per-stage budget, but not the whole tail (claims
+  allow up to maxClaims x 20 s, plus compaction). Before this change the unwired 115 s tick
+  left about 50 s after a 65 s call. Now, with the spec's 90 s, readiness can fill to 70 s
+  and leave 20 s. With the consumer in dry-run (live today), the tail is milliseconds. A
+  live consumer with slow claims could trip the wall-clock assert and fail the run. That is
+  named here; a later tick retries.
+- Ownership loss, cancellation or the wall-clock assert after a call ends the run (failed or
+  cancelled), exactly like any later stage. It is not counted as a provider failure, and the
+  undecided chunk is left untouched.
+- Job body (`feedback-factory-process`): unchanged. A tick that stops on the wall clock is
+  `succeeded` (or `no-op`). A failed call still yields `degraded` /
+  `readiness-authority-failed`, which the job reports.
+- New reason `readiness-wall-clock-exhausted`. It appears only when earlier stages used the
+  whole readiness window and no call was made. The run is degraded and no transient failure
+  is counted.
+
+---
+
+## 6. External surfaces
+
+- Model spend: about 2-3 calls per tick instead of one. At the default $0.01 per call and 48
+  ticks a day, that is about $1.44/day, under the authority's $5/day cap. The cap is still
+  enforced, now before each call.
+- Config: new optional `feedbackFactory.drain.readinessChunkSize`. There is no default in
+  ConfigDefaults (the code default is 10), so no migration is needed.
+  `maxWallClockMs` now takes effect: agents with the shipped 90 s default go from 115 s to
+  90 s per tick, which matches spec §203.
+- No change to prompts, the schema, routes, the dashboard, messaging or the CLAUDE.md
+  template. The template's "three timeouts or provider errors in a row" wording still
+  describes the behaviour.
+
+---
+
+## 6b. Operator-surface quality
+
+Not applicable. No operator surface is touched.
+
+---
+
+## 7. Multi-machine posture (Cross-Machine Coherence)
+
+Unchanged. The drain runs only on the canonical owner machine (owner fence + epoch). Chunking
+is internal to one owner's tick. Proxied ticks behave as before.
+
+---
+
+## 8. Rollback cost
+
+Low. Revert the commit. Setting `readinessChunkSize` to 50 gives back one call per tick
+(which times out live), with no revert needed. No data shape changes: readiness rows, daily
+usage rows and authority records are written with the same columns and meanings.
+
+---
+
+## Conclusion
+
+The change makes the operated readiness stage able to finish on real latency. It respects the
+approved authority envelope (prompt, schema, `maxBatch`, spend cap). Earlier decisions are no
+longer thrown away when a later call fails, and timeouts are not over-counted toward
+demotion. It also brings the tick's wall clock back to the spec's 90 s.
+
+Throughput, measured at ~3.1 s per candidate:
+- About 22 candidates per tick at 90 s, about 30 at 115 s.
+- Every tick is still capped by the authority's `maxBatch`. The live gen 3 authority is
+  narrowed to 10, so the drain stays at 10 per tick (480 a day at the 30-minute cadence)
+  until a generation with a larger `maxBatch` is registered.
+
+## Second-pass review (if required)
+
+**Reviewer:** independent reviewer subagent
+**Independent read of the artifact: concur**
+
+"Concur with the review". The reviewer ran the three new test files (8/8, 2/2, 1/1). The
+non-blocking notes and what was done:
+- Non-numeric `readinessChunkSize` / `maxWallClockMs` from config produced NaN, which stalls
+  or demotes. Fixed: they fall back to 10 and 115 s (unit test).
+- A store error while applying decisions still counted as a success, and re-marked
+  already-approved rows. Fixed: success is counted after apply, and only rows still
+  `collecting` are marked failed (unit test).
+- Ownership loss or the wall-clock assert inside the call's try was counted as a provider
+  failure. Fixed: `stopIfCancelled()` now runs outside it, so the run fails or cancels
+  (unit test).
+- The §5 later-stage wording was inaccurate. Corrected above (named exposure for a live
+  consumer).
+- Left as is (named):
+  - The first call is not sized to the time left (rare; bounded; one transient failure).
+  - When the time left is under 60 s, the service timer fires before the arbiter's own
+    timeout and the codex child keeps running. This is unchanged from before, and 30-minute
+    ticks never overlap.
+
+## Evidence pointers
+
+- Live latency shapes: the Mac Studio store's `drain_runs` (a read-only `.backup` copy). Runs
+  2b4bebb3 and 0e7b229a: 60.1 s, degraded `readiness-authority-failed` (50 candidates). Run
+  20c4fac7: 32.6 s, succeeded (10 candidates). The authority records show gen 3 with
+  `max_batch` 10.
+- `tests/unit/feedback-factory/drain-readiness-chunking.test.ts` (11): fake clock at 3.1 s
+  per candidate, with a 60 s `CodexExecJsonTimeoutError`. Recorded gpt-6-astra decisions are
+  replayed through the unchanged parser. Of the first 8, 7 fail on the pre-fix source; the
+  8th guards the unchanged all-failed demotion rule. The last 3 cover the review fixes.
+- `tests/integration/feedback-drain-readiness-chunking.test.ts` (2): AgentServer wiring of
+  both config fields and HTTP ticks. Both fail on the pre-fix source.
+- `tests/e2e/feedback-drain-readiness-chunking.test.ts` (1): production wiring, the recorded
+  live reports and recorded replies. The second call times out, the first chunk survives, and
+  the next tick finishes the pass. It fails on the pre-fix source.
+
+## Class-Closure Declaration (display-only mirror)
+
+No agent-authored-artifact defect: the defect is in the drain's TypeScript batching. The
+change modifies a bounded retry path inside a scheduled controller, so its convergence is
+stated here:
+- Control-loop edge: one tick makes at most `ceil(maxBatch / readinessChunkSize)` calls
+  (5 at most), and stops earlier on the wall clock.
+- Steady-state bound: any failed call ends the tick's readiness stage.
+- Settling brake: the authority demotes to proposal-only after 3 consecutive ticks with no
+  successful call, after any contract violation, or at the daily spend cap.