proposal(runtime): create Session follow-ups from actionable external conditions

[somewan820]

Parent roadmap: #2469

Let a Session subscribe to a typed external condition and create one safe follow-up Turn when that condition becomes actionable. The core remains provider-neutral; GitHub is only the first adapter.

Problem

Maka preserves a Session's context across turns and restarts, but work often cannot continue until a fact changes outside Maka.

Examples include:

• a maintainer answers a design question;
• a pull-request review or CI run reaches an actionable result;
• a Linear issue changes state;
• a deployment succeeds or fails;
• a required Slack reply arrives;
• an external artifact becomes available.

Today the user must inspect the external system, decide whether the change matters, and manually carry the information back into the correct Session.

The Session already owns the work context. The missing capability is a durable and safe bridge from an actionable external condition back to that Session.

This proposal is a concrete follow-up to #2469's product requirement that users should be able to distinguish work that is waiting for an external condition. It does not propose another task, execution, or event authority.

Desired outcome

Allow a user to explicitly subscribe a Session to a typed external condition. When the external provider confirms that the condition has been satisfied or invalidated, Maka creates exactly one bounded follow-up Turn in the associated Session.

The initial product promise is:

Stop requiring users to manually relay external state changes before a Session can continue analyzing its work.

A subscription authorizes observation and follow-up. It does not automatically authorize code changes or external side effects.

Provider-neutral architecture

The core Runtime should not contain GitHub-specific concepts such as pull requests, reviews, comments, or required checks. It should own only the provider-neutral lifecycle:

external resource
-> subscription
-> event receipt
-> condition evaluation
-> freshness/action gate
-> one Session follow-up

A minimal shared contract could be:

interface ExternalResourceRef {
  providerId: string;
  connectionId: string;
  resourceType: string;
  resourceId: string;
}

interface ExternalConditionSpec {
  typeId: string;
  version: number;
  parameters: PersistedValue;
}

interface ExternalSubscription {
  id: string;
  sessionId: string;
  resource: ExternalResourceRef;
  condition: ExternalConditionSpec;
  mode: 'notify' | 'analyze';
  status: 'active' | 'satisfied' | 'paused' | 'cancelled';
  revision: number;
}

type ExternalConditionEvaluation =
  | { outcome: 'pending' }
  | { outcome: 'satisfied'; evidence: ExternalEvidenceRef[] }
  | { outcome: 'invalidated'; evidence: ExternalEvidenceRef[] };

Each provider adapter owns:

• authentication and connection lifecycle;
• external resource identity;
• webhook, polling, or stream ingestion;
• event decoding and deduplication identity;
• supported condition types and parameter validation;
• provider-specific author and role semantics;
• freshness, ordering, and stable-state rules;
• conversion into a bounded condition evaluation.

The core does not interpret arbitrary provider payloads or persist an unrestricted JSONPath or natural-language predicate.

Example providers

Provider	Example condition
GitHub	maintainer replied, review changed, required CI settled
Linear	issue assigned, state changed, blocker removed
Slack	reply from a selected person or channel arrived
Deployment	rollout succeeded, failed, or was rolled back
Artifact store	requested artifact became available
Calendar	a selected meeting ended or reached its start time

GitHub would be the first adapter, not the definition of the architecture.

Concrete GitHub journey

While working on apache/maka#2290, the Agent determines that implementation cannot proceed until a maintainer answers the migration questions. After user confirmation, Maka creates a subscription:

Resource: github/apache/maka/issues/2290
Condition: github.issue.maintainer_reply.v1
Mode: analyze

When a matching reply arrives, the GitHub adapter validates the event and evaluates the condition. The core then checks that the subscription remains active and creates one external-follow-up Turn in the original Session. The Agent analyzes the reply and reports the resulting implementation boundary.

Wake invariant

A follow-up Turn may be created only when:

verified provider event
+ matching active subscription
+ condition satisfied or invalidated
+ fresh resource/version identity
+ actionable for this Session
= one follow-up Turn

A stable event is not necessarily relevant. For example, successful CI must not wake a Session whose condition is waiting for a maintainer decision.

Provider adapters own provider-specific stable-state rules. For GitHub:

• a required failure may satisfy the condition immediately;
• required-check success waits for all required checks;
• optional checks normally update projection only;
• a check result for an older head SHA is stale.

Authority boundaries

Concern	Authority
External resource facts	External provider
Provider-specific event meaning	Provider adapter
What condition is being awaited	External subscription
Work identity and conversation	Session
Execution results	AgentRun / RuntimeEvent
Code and revision freshness	Git, filesystem, external provider
Permission to modify or publish	Existing permission/action policy
WorkHub display	Rebuildable projection

I do not propose adding waiting_for_external to SessionStatus initially. External waiting can be projected from active subscriptions.

Safety

External payloads are untrusted input, not instructions.

The initial analyze mode may refresh state, inspect evidence, and report, but must not modify code, commit, push, merge, or perform external side effects.

Any future automatic-action mode requires a separate deterministic Action Gate covering permissions, repository scope, current revision, dirty worktrees, stale events, idempotency, and scope expansion.

Relationship to existing mechanisms

This is distinct from:

• Scheduled Tasks: time-based triggers;
• Goal continuation: continuation from internal terminal Turns;
• Runtime Resume: recovery of interrupted execution;
• WorkHub: conversational routing and coordination;
• Work Board: user-owned deferred work;
• SessionTodo: model-authored local progress.

The feature should reuse existing Session admission, execution, recovery, and permission mechanisms. A satisfied external condition should normally create a new root Turn with typed external-event provenance.

Proposed MVP

• provider-neutral subscription and delivery core;
• GitHub as the first production adapter;
• a fake provider used in contract tests to prove core independence;
• explicit user-confirmed, one-shot subscriptions;
• GitHub issue comments, reviews, required CI, close/reopen/merge;
• analyze-only follow-ups;
• durable receipts, cursors, deduplication, and restart recovery;
• polling allowed as the first transport;
• visible subscription state and cancellation;
• no automatic code modification.

A second provider should be addable without changing the core subscription schema or Session wake protocol.

Alternatives or workarounds

• Manual relay: the user continues checking external systems and pasting updates into the Session. This is the current behavior and the coordination burden this proposal aims to remove.
• Scheduled polling Turns: a recurring Agent Turn checks the external resource. This consumes work while nothing changed and still needs durable deduplication, relevance, and freshness semantics.
• GitHub-specific watcher: faster initially, but it would couple Session continuation to GitHub resource types and make each later provider repeat the subscription and delivery lifecycle.
• Natural-language conditions evaluated by a model: flexible, but too weak as the durable authority for deduplication, stable-state decisions, and safe wake admission.

Non-goals

• A universal workflow engine.
• Arbitrary natural-language or JSONPath conditions.
• Automatically subscribing every mentioned resource.
• Waking every Session that references the same resource.
• Treating semantic matching as execution authorization.
• Automatic code modification, commit, push, or merge.
• Modeling all providers with one lossy universal event vocabulary.

Open questions

1. Is this product promise useful for ordinary Sessions?
2. Should the subscription and delivery authority live in Runtime Host?
3. Should providers register versioned condition schemas and evaluators?
4. Should a satisfied condition use the existing root-Turn admission path?
5. Is GitHub polling an acceptable first transport?
6. Should the first version support only one-shot subscriptions?
7. Where should subscriptions be created and inspected?
8. Which second adapter would best prove that the core is genuinely provider-neutral?

I would like to settle the product contract and ownership boundary before proposing a storage schema or implementation PR.

简体中文

问题

Maka 能跨 Turn 和重启保存 Session 上下文，但很多工作必须等待 Maka 之外的事实发生变化后才能继续。例如 maintainer 回复设计问题、PR review 或 CI 得出结果、Linear issue 状态变化、部署完成、Slack 中收到关键回复，或者外部产物生成完成。

目前仍需要用户查看外部系统、判断变化是否重要，再把信息搬回正确的 Session。缺失的能力是：从可行动的外部条件安全、持久地回到原 Session。

这个提案是 #2469 中“用户应该能够识别正在等待外部条件的工作”这一产品要求的具体后续。它不新增另一套 Task、执行或事件权威。

目标

允许用户明确地为 Session 订阅一个强类型外部条件。当外部 provider 确认条件已经满足或失效时，Maka 在关联 Session 中只创建一个受限的 follow-up Turn。

订阅只授权观察和唤醒，不自动授权修改代码或产生外部副作用。

通用架构

核心 Runtime 不应该理解 GitHub 的 PR、评论、review 或 CI。核心只负责：

外部资源
-> 订阅
-> 事件收件
-> 条件评估
-> 新鲜度与行动门禁
-> 一次 Session follow-up

每个 provider adapter 负责认证、资源身份、事件接收、去重、条件类型、参数校验、作者角色、事件顺序、新鲜度以及稳定状态判定。

GitHub 只是第一个 adapter，而不是整个架构的定义。相同核心以后可以接入 Linear、Slack、部署平台、Artifact Store 或 Calendar。

核心不应直接解释任意 provider payload，也不应保存无限制的 JSONPath 或自然语言条件。自然语言可以帮助用户准备条件，但最终应落为经过 adapter 校验的版本化条件契约。

GitHub 示例

在处理 apache/maka#2290 时，Agent 判断只有 maintainer 回答迁移问题后才能安全规划实现。经用户确认后，Maka 创建一次性 analyze 订阅。

回复到达后，GitHub adapter 验证事件并评估条件；核心检查订阅仍有效、事件没有过期，然后在原 Session 中创建一个 follow-up Turn。Agent 分析回复并报告实现边界。

唤醒条件

只有同时满足以下条件才能创建 follow-up Turn：

来源可信
+ 匹配有效订阅
+ 条件满足或失效
+ 资源版本仍然最新
+ 对当前 Session 可行动
= 一次 follow-up Turn

稳定事件不一定相关。例如 Session 等待 maintainer 决策时，CI 成功不能唤醒它。

权威边界

外部 provider 持有外部事实；provider adapter 解释事件；subscription 持有等待条件；Session 持有工作身份和对话；AgentRun/RuntimeEvent 持有执行结果；现有权限策略决定是否允许修改或发布。

第一版不新增 waiting_for_external Session 状态，而是从有效订阅投影“正在等待外部条件”，避免出现第二份状态权威。

安全

外部 payload 是不可信输入，不是指令。

第一版只支持 analyze：刷新状态、检查证据和报告结论，不允许自动修改代码、commit、push 或 merge。未来自动行动必须经过独立的确定性 Action Gate。

与现有机制的关系

它不同于按时间触发的 Scheduled Tasks、消费内部 Turn 的 Goal continuation、恢复中断执行的 Runtime Resume、负责对话路由的 WorkHub、用户拥有的 Work Board，以及模型自报进度的 SessionTodo。

它应该复用现有 Session admission、执行、恢复和权限机制，而不是建立新的执行引擎。

MVP

• provider-neutral 的 subscription/delivery 核心；
• GitHub 作为首个生产 adapter；
• 使用 fake provider 测试核心确实不依赖 GitHub；
• 用户明确确认的一次性订阅；
• 支持评论、review、required CI、close/reopen/merge；
• analyze-only；
• 持久化 receipt、cursor、去重和重启恢复；
• 第一版允许 polling；
• 可以查看和取消订阅；
• 不自动修改代码。

第二个 provider 应能在不修改核心 subscription schema 和 Session 唤醒协议的情况下接入。

非目标

• 通用工作流引擎；
• 任意自然语言或 JSONPath 条件；
• 自动订阅所有被提到的资源；
• 唤醒所有引用同一资源的 Session；
• 把语义匹配当成执行授权；
• 自动修改代码、commit、push 或 merge；
• 用一套有损的通用事件词汇抹平所有 provider 差异。

待确认问题

1. 普通 Session 是否需要这个产品承诺？
2. subscription/delivery 权威是否属于 Runtime Host？
3. provider 是否应该注册版本化 condition schema 和 evaluator？
4. 条件满足后是否复用现有 root-Turn admission？
5. GitHub-first 是否可以先使用 polling？
6. 第一版是否只支持一次性订阅？
7. 用户在哪里创建和查看订阅？
8. 第二个 provider 选什么，最能验证通用性？

在设计存储 schema 或实现 PR 之前，我希望先确认产品契约和所有权边界。

AI assistance disclosure: Codex helped structure and draft this proposal from a product and architecture discussion. I reviewed it and own the problem statement, proposal, and final decisions.

[cat0825]

Revising my earlier comment after reading the source. My previous take was built from the linked issues rather than the code, and two of its load-bearing claims were wrong. The corrected picture makes the case for this proposal stronger, but it reframes what the proposal is actually asking for.

Correction 1: durable waiting already exists

I said the waiting substrate would need to be built. It is already there, and it already names your exact use case:

/** The agent is blocked waiting on an external event (CI, deploy, review). */
waiting: boolean;

packages/runtime/src/goal-evaluator.ts:44-45

waiting is a first-class persisted status (packages/core/src/goal.ts:22-32), exponential backoff is implemented (GOAL_WAIT_BACKOFF_BASE_MS = 5_000 to GOAL_WAIT_BACKOFF_MAX_MS = 5 * 60_000, goal-continuation.ts:113-114), restart recovery preserves it (recoverActiveGoal accepts status === 'waiting', goal-continuation.ts:451), and even the UI copy exists — goalWaitingAriaLabel: 'Autonomous goal waiting for conditions to change' (packages/ui/src/conversation-copy.ts:682).

This cuts both ways. The cost is lower than I estimated, but it makes the "Relationship to existing mechanisms" boundary harder to defend: the branch that handles waiting for CI, deploy, or review is already inside Goal continuation. I still think this should be framed as a second wake source for that loop rather than a distinct lifecycle — but for a different reason than I gave before.

Correction 2: there is no not_before to generalize

I claimed #3194 already has a not_before on a pending Step that this proposal could extend. That was wrong. Searching the repository, notBefore exists only in packages/core/src/cron-expression.ts:43 and packages/core/src/scheduled-task.ts:256, with zero references from the Goal path. The UNIQUE(goal_id, step_number) I quoted does not exist either; durable Goal state is a single row per session in workflow_goal_authority (packages/storage/src/sqlite-workflow-schema.ts:142-150), keyed session_id PRIMARY KEY, with no time column and no deadline index — so "find all Goals due now" is not an expressible indexed query today.

Adding one is also not an additive write. GOAL_STATE_SHAPE's optional set is closed — ['tokenBudget', 'lastReason', 'achievedAt', 'pausedAt', 'armedAt'] (goal.ts:145) — and validated by hasExactShape, so a new field means touching the shape, decodeGoalState (goal.ts:188-217), and schemaVersion.

What the real argument is: the existing wait is a blind re-poll that spends budget

Three defects, all verified:

It checks nothing external. scheduleWaitingRetry fires a timer, calls wakeWaiting, then scheduleDrain (goal-continuation.ts:883-908). No predicate, no subscription, no callback. The turn itself re-discovers whether CI finished, and the evaluator re-judges from its text.

Each blind poll spends an iteration, and maxIterations is the only thing bounding a wait. In settleTurn the order is iterations++ (goal-state.ts:360-366), then the blockCap check (:368-378), and only then the waiting branch (:380-382), so a waiting verdict is charged an iteration before it is recognized as waiting. It is not charged a stall tick: the waiting: true arm of GoalTurnSettlementInput types madeProgress as never (:93-108) and the caller passes only waiting and tokensNow (goal-continuation.ts:715-721), so the input.madeProgress !== undefined guard is always false on that path. Contrast achieved and impossible, which return early and touch no counters (:325-334), with a test asserting exactly that — 'terminal evaluator verdict settles without advancing turn counters' (goal-state.test.ts:296-309).

I want to be careful about calling the iteration charge a bug, because it is currently load-bearing. There is no separate cap on waiting: no maxWaits, no wait TTL, nothing (MAX_WAITING_CODE_MODE_CELLS in ai-sdk-backend.ts:910 is unrelated). maxIterations is the only thing that stops a Goal from waiting forever on a condition that never arrives. So "don't charge waiting turns" cannot land on its own — it would remove the sole bound on an unbounded wait. It has to arrive together with the TTL and per-subscription wake cap I mentioned above, which makes it part of this proposal rather than independent groundwork. What is unambiguously wrong today is the accounting: a wait consumes the budget meant for doing work, so turn 14/50 in the continuation prompt may mean two turns of work and twelve polls.

The backoff is not durable. consecutiveWaits lives on the in-memory SessionLane (goal-continuation.ts:157) and recoverActiveGoal rebuilds the lane with consecutiveWaits: 0 (:533) — a Goal that had backed off to 5 minutes resumes at 5 seconds. The timer is also unref'd (:994-996), and no production code injects a scheduler, so an otherwise-idle Host can exit with a wake pending.

So the proposal's argument should not be "we need the ability to wait." It should be "the existing wait is an unconditioned poll that charges the task's own iteration budget for time spent idle, and it should become condition-driven." That is a much stronger claim and a measurable one.

Correction 3: #3386 does not say what I said it says

I repeated a claim that scheduled-task status is encoded as a fake permission mode. It is not. PERMISSION_MODES is exactly ['explore', 'ask', 'bypass'] (packages/core/src/permission.ts:26). Every scheduled-task reference to permissionMode is ordinary session config being carried forward — captured from the originating session header (scheduled-task-coordinator.ts:806), validated by isPermissionMode on the way in, replayed into createSession (:645). Real scheduled-task state lives in dedicated fields: status, nextFireAt, fireCount, and the claim's own nativeState. That inherited-debt warning was unfounded; disregard it.

Where exactly-once actually lives today: not in the database

This is the part that changed most. I worried a second delivery path would implement the dual-write window twice. The real situation is that the first implementation does not close it either, so there is no proven mechanism to inherit.

The state transition is a synchronous in-memory mutation (goal-state.ts:189-198); persistence is a fire-and-forget promise lane (goal-coordinator.ts:541-573). ContinuationIntent (goal-continuation.ts:128-133) is never written to disk. In drainLane, the flush is at :606 and admission at :618 — admission is outside the flush. Crash in between and the intent is gone; recoverActiveGoal then reconstructs a synthetic intent with evaluatorFailed: true (:454-461) rather than replaying the original.

Exactly-once is enforced by three process-local mechanisms — the single-slot intent scalar, the settle closure from beginObservedTurn, and reserveIfIdle's synchronous reservation (goal-turn-lifecycle.ts:78-81). Across processes there is only the single-row revision CAS on workflow_goal_authority (goal-authority.ts:194-199), which fails a second writer at commit — after it has already started a turn.

The codebase does contain a correct fence, just not here. The continuation-claim table uses boundary_digest ... UNIQUE, target_invocation_id TEXT NOT NULL UNIQUE, plus a four-column composite UNIQUE (packages/storage/src/sqlite-runtime-schema.ts:150-171). And workflow_scheduled_task_fires has task_id TEXT NOT NULL UNIQUE (sqlite-workflow-schema.ts:79-84), giving "at most one in-flight fire per task" at the storage layer. Those are the models to copy — not the Goal path.

My storage suggestion stands, with a correction to the key. Intake: UNIQUE(connection_id, provider_event_id) on a durable receipt table, since polling re-observes the same comment repeatedly. Wake: one-shot makes the subscription itself the dedup key, so a plain UNIQUE(subscription_id) on the successor-intent table suffices — replays can only ever insert one. That remains the real argument for keeping v1 one-shot (Q6): it collapses correctness into one constraint.

Storage substrate: sound, but do not extend the scheduled-task table

The foundation is better than I assumed. node:sqlite DatabaseSync over one connection per workspace, real cross-table transactions via a re-entrant transaction('write', …) mapping to BEGIN IMMEDIATE (operational-state-store.ts:257-272), WAL with synchronous = FULL, a numbered migration ladder on PRAGMA user_version that fails closed on newer-than-supported (sqlite-runtime-schema.ts:345-370), and cross-process exclusivity via an advisory owner.lock (root-authority.ts:721). Enough to build on.

But workflow_scheduled_tasks cannot carry subscriptions. Every write is a full-table rewrite — DELETE FROM both tables, then re-insert every row, each task serialized whole into record_json (scheduled-task-store.ts:637-655). Condition fields in a JSON blob are neither indexable nor queryable, and it is sized for the 256-task cap. Also worth knowing: mutate reads state outside the transaction and only the write is atomic (:625-635), so correctness rests on the in-process queue plus the exclusive file lock, not on database isolation. Subscriptions need properly modeled rows.

Q2 is already answered by ARCHITECTURE.md

ARCHITECTURE.md:24 and :41: one execution authority, and Runtime Host "owns Session and Turn identity, agent lifecycle, continuation, tools, permissions, and events." GoalContinuationCoordinator lives in packages/runtime but its only construction site is packages/runtime-host/src/server/goal-coordinator.ts:157; CLI and Desktop are clients. So Runtime Host is not one option among several — it is the only placement consistent with the existing layering. The #3231 sequencing caveat still applies.

The wake path is worth copying verbatim

ScheduledTaskCoordinator does this cleanly: #root.admit(...) → sendMessage with four pre-minted UUIDs, durability: 'required', and origin: { kind: 'scheduled_task' } (scheduled-task-coordinator.ts:651-682). A fire is synthesized as a user-message turn carrying an origin tag. The claim/settle lifecycle is the part to imitate: bindFireExecution persists the execution identity before any work, and on recovery a claim with no bound execution is failed rather than retried (:189-213) — because the Host cannot know whether the turn landed. assertRecoveryAdmission then re-checks the replayed admission field-by-field, including message content, and throws on divergence (:166-187). That is correct at-most-once, and it is the shape an external wake should take.

A UI gap nobody has raised

packages/ui/src/status-vocabulary.ts:48 sets the rule: waiting on the SYSTEM is active, waiting on the USER is attention, and collapsing the two is the mistake the vocabulary exists to prevent. "Waiting on an external condition" is neither — nobody needs to look at it, but nothing is running. session-status-presentation.ts:62 currently maps waiting_for_user to attention. Picking a mapping here needs a deliberate decision, or a parked subscription reads as either actionable or busy.

Revised slicing

The first PR should touch neither GitHub, credentials, nor webhooks: add a condition wake source to the existing waiting loop, plus one zero-auth local provider (a long-running command exits, an expected artifact appears). That validates three things at once — whether the product contract holds, whether the wake protocol is right, and whether waiting can stop charging the iteration budget. It also answers Q8 for free: a local condition provider is an order of magnitude cheaper than Slack and proves provider-neutrality just as well.

Groundwork to file separately, because each is a real change rather than a detail: the GoalState schema extension (closed hasExactShape validation), moving consecutiveWaits onto persisted state, and the subscription table with its UNIQUE fence.

Iteration accounting for waits belongs inside this proposal rather than beside it, for the reason above: maxIterations is currently the only bound on a wait, so the charge cannot be removed until a TTL and a per-subscription wake cap exist to replace it. Sequencing it that way also avoids a trap — if waits stopped consuming iterations before any other bound existed, a condition that never arrives would poll indefinitely, which is a worse failure than the current one. The credential and connection layer remains the most likely place to stall (github integration, connection oauth, polling cursor all return nothing), but the first PR does not need it.

My earlier points on budget caps, subscription TTL, an allowlist definition of analyze (with git fetch excluded, since it mutates .git), and keeping waiting_for_external out of SessionStatus all stand unchanged. One note on budget: a tokenBudget and a budget_limited status already exist (goal.ts:56, :30), but the baseline is established by the first settling turn (tokensBaselinePending, goal-state.ts:343-348), so a wake-based successor that bypasses settleTurn would never set a baseline and the budget would silently never engage.

One thing I did not verify: GoalContinuationScheduler (goal-continuation.ts:77-80) is an existing injection point, already substituted in tests via ManualScheduler, and looks like the natural seam for a condition-aware scheduler — but I did not implement against it, so I cannot say whether async condition evaluation fits that interface as-is.

简体中文摘要

读了源代码后修正上一条评论，其中两处硬错误要撤回。

撤回一：持久等待已经存在。 waiting 是一等持久状态，指数退避已实现（5 秒到 5 分钟），重启能恢复，evaluator 的注释写的就是「等 CI / 部署 / review」，连 UI 文案都有。所以成本比我上轮估的低，但这也意味着「和 Goal continuation 不同」这个划分更站不住 —— 那个分支就在 Goal continuation 里面。

撤回二：没有 not_before 可以泛化。 我说 #3194 已有 not_before 和 UNIQUE(goal_id, step_number)，都不存在。notBefore 只在 cron/scheduled-task 里，跟 goal 零引用。持久 Goal 状态是每 session 一行，没有时间列也没有截止索引。而且 GOAL_STATE_SHAPE 是 hasExactShape 封闭校验，加字段是 schema 变更。

撤回三：#3386 那个「假 permission mode」不成立。 PERMISSION_MODES 就是三个值，scheduled task 状态走专属字段。那条债务警告作废。

真正的论证应该是：现有等待是烧迭代预算的盲目轮询。 定时器到点不检查任何外部状态，靠 turn 自己重新发现 CI 完了没有。settleTurn 里 iterations++（:360-366）在 waiting 分支（:380-382）之前，所以每次盲目轮询都吃一次迭代。但它不吃 stall tick —— waiting: true 那支把 madeProgress 类型约束成 never（:93-108），调用方也只传 waiting 和 tokensNow（goal-continuation.ts:715-721）。这点要说清楚，因为那个迭代计费目前是承重的：全仓库没有任何针对等待的独立上限，maxIterations 就是唯一阻止无限等待的东西。所以「别给等待计费」不能单独落地，必须和 TTL、每订阅唤醒上限一起来 —— 这也是为什么它属于本提案内部，而不是可以先行的独立修复。今天真正错的是账目：等待花掉的是留给干活的预算，turn 14/50 可能意味着 2 次工作 + 12 次轮询。另外退避等级不持久（重启回到 5 秒），定时器还 unref 了。

exactly-once 现在不在数据库里。 状态提交和后继入队不在同一事务、甚至不在同一介质；intent 纯内存从不落盘；恢复是重建合成 intent 而非重放。三层去重全是进程内的。但代码库里有做对的样板：continuation claim 表的复合 UNIQUE，和 workflow_scheduled_task_fires 的 task_id UNIQUE。该抄这个。

存储基础可用，但 scheduled-task 那张表不能扩 —— 每次写是全表重写，条件字段在 JSON blob 里无法索引，按 256 条上限设计。

Q2 文档里已有答案： ARCHITECTURE.md 明确写 Runtime Host owns continuation，唯一实例化点也在 runtime-host。

切法修正： 第一个 PR 只给现有 waiting 循环加条件唤醒源 + 一个零认证本地 provider，不碰 GitHub / 凭据 / webhook。这同时回答了 Q8。迭代计费的修正要和 TTL、唤醒上限打包在这个 PR 里，不能先行 —— 先拆掉唯一的兜底会让永不满足的条件无限轮询，比现在更糟。

预算上限、订阅 TTL、analyze 白名单（排除 git fetch）、不给 SessionStatus 加字段，这几条不变。补一点：tokenBudget 已存在，但基线由第一个结算 turn 建立，绕过 settleTurn 的唤醒式后继会导致预算永不生效。

---

_{AI assistance disclosure: I used Claude Code to read this repository's Goal continuation, scheduled-task, and storage layers and to draft this comment. The review positions and conclusions are mine.}