Back to corpus
architecturetechnical paper candidatescore 40

Task Board + Ledger Architecture

> Deterministic multi-agent task system with evidence-gated completion, terminal state locks, and append-only audit ledger.

Full HTML reader

Read the full artifact

Open in new tab

Extracted abstract or opening context

> Deterministic multi-agent task system with evidence-gated completion, terminal state locks, and append-only audit ledger. 1. Every task has a UUID (`mac_tasks.id`) 2. Every task lives in Supabase `mac_tasks` table 3. DONE requires real proof — output (>50 chars), commit hash, or verified URL 4. Placeholder URLs are rejected (localhost, [ip], example.com) 5. Parent tasks cannot close while children are still open 6. Once a task is DONE, it stays DONE — no status regression 7. Every state transition is logged to append-only `task_events` ledger | Column | Type | Purpose | |--------|------|---------| | `id` | uuid | Primary key | | `task_content` | text | The task prompt | | `project_path` | text | Target project directory | | `source` | text | Origin: discord, sms, telegram, api | | `status` | text | pending → running → complete/failed | | `claimed_by` | text | Device that claimed (mac1, mac4, cloud-vm) | | `parent_task_id` | uuid | FK to parent (for subtasks) | | `team_id` | uuid | Team grouping ID | | `team_role` | text | team_lead, worker, aggregator | | `model_preference` | text | Requested model | | `model_used` | text | Actual model that responded | | `output` | text | Task result | | `commit_hash` | text | Git evidence | | `evidence_url` | text | URL evidence | | `evidence_type` | text | output, commit, url, or multiple | | `exit_code` | int | Process exit code | | `attempt_count` | int | Current attempt number | | `max_attempts` | int | Max retries before terminal fail | | `error_log` | text | Append-only failure log | | `timeout_at` | timestamptz | Auto-reclaim deadline | | `relay_from` | text | Previous device (on handoff) | | `relay_to` | text | Target device (on handoff) | | `relay_reason` | text | timeout, manual, capability | | `admissibility_token` | text | HMAC policy compliance proof | | `discord_thread_id` | text | Linked Discord thread | | `result_delivered` | bool | Prevents duplicate delivery | | Timestamps | timestamptz | created_at, started_at, completed_at | | Column | Type | Purpose | |--------|------|---------| | `id` | uuid | Event ID | | `task_id` | uuid | FK to mac_tasks | | `event_type` | text | created, claimed, completed, failed, reclaimed, evidence_blocked, terminal_blocked, dependency_blocked | | `from_status` | text | Previous status | | `to_status` | text | New status | | `agent_id` | text | Who triggered the transition | | `evidence` | jsonb | Evidence payload (has_output, has_commit, has_url) | | `metadata` | jsonb | Context (relay info, block reasons, etc.) | | `created_at` | timestamptz | When the event occurred | **Terminal states**: `complete` (always), `failed` (when attempt_count >= max_attempts)

Promotion decision

What has to happen next

Promote into a technical note or architecture paper with implementation anchors.

Why this is not always a full paper yet

Corpus pages are public-safe readers for discovered workspace artifacts. They are not automatically final papers. A corpus item becomes a polished paper only after the editable source, evidence checkpoints, references, figures, render path, and release status are attached through the paper schema.