Goals end at achieved, not at an empty board: the goal-review loop

The board draining to 280/280 done left the company idle under a
still-active goal, with 24 markdown files and zero code as its life's work.
Two structural gaps caused it: goals had no lifecycle (status was written
once as 'active' and never read again — nothing re-engages anyone when the
last task closes), and nothing anywhere distinguished plans from product,
so every "engineering" objective closed on documents.

The loop, closed:
- tasks.origin (migration 055) records provenance: chat_wake for mention
  vehicles (backfilled from their runs), goal_review for checkpoints, null
  for real work. Chatter and checkpoints can therefore never count as
  progress.
- spawnGoalReviews (each worker tick): an active goal with zero open tasks
  and real progress since the last review gets ONE review task for the goal
  owner. The review demands evidence — list the workspace, read the code,
  run the tests; documents are how work starts, not proof it happened — and
  must end in exactly one of: complete_goal, or the next wave of tasks with
  requires_filesystem engineering. A review closed with neither spawns
  nothing: termination is structural, not a counter.
- complete_goal (CEO or goal owner) finally lets someone say a goal is
  achieved, audited.
- CEO and department-head voices now state the doctrine: a goal that
  promises software closes on code that builds and passes tests in the
  workspace, and implementation is delegated with requires_filesystem: true.

On the live profile this arms one review: the active platform goal has 0
open tasks and 21 real completed ones, so the CEO gets the checkpoint on
next launch and the company starts building instead of stopping.

src/main/database/migrations/055-task-origin.ts

@@ -0,0 +1,18 @@
+export const taskOriginSchema = `
+  -- Task provenance. 'chat_wake' marks conversation vehicles created by a
+  -- mention wake, 'goal_review' marks the CEO's goal checkpoints; plain work
+  -- (kickoffs, agent- and operator-created tasks) stays null. The goal-review
+  -- scheduler needs this to tell real progress from chatter — otherwise every
+  -- auto-closed reply task would count as progress and reviews would spawn
+  -- forever.
+  alter table tasks add column origin text;
+
+  -- Backfill: every existing wake vehicle is identifiable by its chat_mention
+  -- run (only the wake service ever creates those runs).
+  update tasks set origin = 'chat_wake'
+  where origin is null
+    and exists (select 1 from task_runs r where r.task_id = tasks.id and r.trigger = 'chat_mention');
+
+  insert into schema_migrations(version, name, applied_at)
+  values (55, 'task_origin', datetime('now'));
+`;

src/main/database/schema.ts

@@ -53,6 +53,7 @@ import { purgeRuntimeSnapshotBloatSchema } from "./migrations/051-purge-runtime-
 import { avatarImagesSchema } from "./migrations/052-avatar-images";
 import { autonomousPauseSchema } from "./migrations/053-autonomous-pause";
 import { closeStaleWakeTasksSchema } from "./migrations/054-close-stale-wake-tasks";
+import { taskOriginSchema } from "./migrations/055-task-origin";
 
 interface Migration {
   version: number;
@@ -115,6 +116,7 @@ const MIGRATIONS: Migration[] = [
   { version: 52, name: "avatar_images", sql: avatarImagesSchema },
   { version: 53, name: "autonomous_pause", sql: autonomousPauseSchema },
   { version: 54, name: "close_stale_wake_tasks", sql: closeStaleWakeTasksSchema },
+  { version: 55, name: "task_origin", sql: taskOriginSchema },
 ];
 
 const SCHEMA_VERSION = MIGRATIONS[MIGRATIONS.length - 1].version;