Tighten Linear review gate and usage startup

Author: arul28

apps/ade-cli/src/bootstrap.ts

@@ -978,7 +978,6 @@ export async function createAdeRuntime(args: {
     pollIntervalMs: 120_000,
     onUpdate: (snapshot) => pushEvent("runtime", { type: "usage", snapshot }),
   });
-  usageTrackingService.start();
   const budgetCapService = createBudgetCapService({
     db,
     logger,
@@ -1203,6 +1202,7 @@ export async function createAdeRuntime(args: {
   };
   automationService.bindAdeActionRegistry(adeActionLookup);
 
+  usageTrackingService.start();
   runtimeCreated = true;
   return runtime;
   } finally {

apps/desktop/src/main/services/cto/linearDispatcherService.ts

@@ -2436,7 +2436,7 @@ export function createLinearDispatcherService(args: {
       if (run.status !== "awaiting_human_review") {
         throw new Error("This workflow run is not awaiting supervisor review.");
       }
-      if (!currentStep || currentStep.type !== "request_human_review" || !reviewContext) {
+      if (!currentStep || currentStep.type !== "request_human_review" || !currentStepRow || !reviewContext) {
         throw new Error("This workflow run is not on a human review step.");
       }
       updateRun(run.id, {

apps/desktop/src/main/services/cto/linearSync.test.ts

@@ -2263,8 +2263,8 @@ describe("linearDispatcherService (file group)", () => {
       db.close();
     });
 
-    it("rejects early approve before the supervisor review gate is active", async () => {
-      const root = fs.mkdtempSync(path.join(os.tmpdir(), "ade-linear-dispatcher-early-approve-"));
+    it.each(["approve", "reject"] as const)("rejects early %s before the supervisor review gate is active", async (action) => {
+      const root = fs.mkdtempSync(path.join(os.tmpdir(), "ade-linear-dispatcher-early-review-action-"));
       const db = await openKvDb(path.join(root, "ade.db"), { debug() {}, info() {}, warn() {}, error() {} } as any);
       const policy = buildSupervisedWorkerPolicy();
 
@@ -2312,8 +2312,11 @@ describe("linearDispatcherService (file group)", () => {
       expect(detailBeforeReview?.run.status).not.toBe("awaiting_human_review");
 
       await expect(
-        dispatcher.resolveRunAction(run.id, "approve", "Pre-approved.", policy),
+        dispatcher.resolveRunAction(run.id, action, "Pre-resolved.", policy),
       ).rejects.toThrow("not awaiting supervisor review");
+      const detailAfterRejectedAction = await dispatcher.getRunDetail(run.id, policy);
+      expect(detailAfterRejectedAction?.run.status).toBe(detailBeforeReview?.run.status);
+      expect(detailAfterRejectedAction?.run.reviewState).not.toBe(action === "approve" ? "approved" : "rejected");
 
       const awaitingReview = await dispatcher.advanceRun(run.id, policy);
       expect(awaitingReview?.status).toBe("awaiting_human_review");

docs/features/linear-integration/dispatch-and-sync.md

@@ -205,7 +205,11 @@ A run's steps advance via `currentStepIndex`. For each step type:
   on timeout the step is marked failed with `review_timeout` and the
   run advances rather than stalling. `rejectAction` drives the
   rejection path (`cancel`, `reopen_issue`, or `loop_back` which
-  resets `currentStepIndex` to `loopToStepId ?? "launch"`).
+  resets `currentStepIndex` to `loopToStepId ?? "launch"`). Approve
+  and reject actions are only valid while the run status is
+  `awaiting_human_review` and the current step row is still a
+  `request_human_review` step; early or stale resolutions throw
+  without mutating `reviewState`.
 - `emit_app_notification` — broadcasts a
   `linear-workflow-notification` event via
   `ctoLinearWorkflowEvent` IPC. The renderer listens in `CtoPage` and

docs/features/remote-runtime/internal-architecture.md

@@ -37,7 +37,7 @@ Runtime event streaming uses `ade/actions/call` with `name: "stream_events"` for
 
 Each `stream_events` response carries a per-runtime `eventEpoch` UUID minted when the daemon's `eventBuffer` is constructed. The preload event pump compares it against the last seen epoch for the active binding; if it changes (daemon restart, ssh reconnect to a fresh process) the cursor and dedup set reset and the next poll starts from `cursor=0`. The `startedAtMs` "drop events older than the pump start" filter is only applied to **local** bindings — remote pumps rely on the epoch reset instead, so older events backfilled after a reconnect are still delivered.
 
-The remote event allowlist (`toRemoteRuntimeBufferedEvent`) accepts the runtime event categories desktop renders today: `category in {agent_chat, terminal, lane, pr, file_watch, process, test, project_state, orchestrator, dag_mutation, runtime, pty}`. The runtime additionally emits source-tagged events that preload routes to dedicated remote subscribers: `usage`, `usage_threshold`, `automation_event`, `conflict_event`, `github_status_changed`, `linear_workflow_event`, `feedback_submission_event`, `computer_use_event`, `ios_simulator_event`, `app_control_event`, and `macos_vm` (re-keyed to its `eventType`). ade-cli wires these into the runtime event buffer in `bootstrap.ts` so a remote-bound window sees the same usage, automation, conflict, GitHub, Linear, feedback, Computer Use, iOS Simulator, App Control, and macOS VM events as the local host.
+The remote event allowlist (`toRemoteRuntimeBufferedEvent`) accepts the runtime event categories desktop renders today: `category in {agent_chat, terminal, lane, pr, file_watch, process, test, project_state, orchestrator, dag_mutation, runtime, pty}`. The runtime additionally emits source-tagged events that preload routes to dedicated remote subscribers: `usage`, `usage_threshold`, `automation_event`, `conflict_event`, `github_status_changed`, `linear_workflow_event`, `feedback_submission_event`, `computer_use_event`, `ios_simulator_event`, `app_control_event`, and `macos_vm` (re-keyed to its `eventType`). ade-cli wires these into the runtime event buffer in `bootstrap.ts` so a remote-bound window sees the same usage, automation, conflict, GitHub, Linear, feedback, Computer Use, iOS Simulator, App Control, and macOS VM events as the local host. Headless runtimes start `usageTrackingService` during `createAdeRuntime()` after the ADE action registry is bound, so the usage poller and threshold events run only once the runtime can answer the matching usage/budget actions.
 
 ## SSH transport