Commission Human Surface — Product, UX, Design and Implementation Specification

The complete implementation brief for Commission’s human-facing application. Broader than a visual spec: it covers the product model, why the human surface exists, the UX principles that follow, visual direction, information architecture, Jira semantics, collaboration, backend contracts, the component system, the screen inventory, delivery order and acceptance criteria.

Owned by relay-122. The task graph decomposed from it hangs beneath that task — see commission show relay-122 and commission board --project relay.

1 · Executive summary

Commission is the execution layer for software delivery. It coordinates the task graph, execution environment, shared context, claims, gates, evidence, approvals and history across humans and AI agents.

Agents operate it. Humans are asked only for judgment.

The dashboard must not resemble a project-management system whose purpose is helping humans move work through statuses. The human surface exists for four reasons:

1. Show where human judgment is required.
2. Make completed work believable through visible proof.
3. Explain what happened while the human was away.
4. Allow observation of execution without forcing the human to operate the machinery.

It should feel like an operating system for software execution, not a ticket tracker.

2 · Product definition

Commission turns goals into verified software by coordinating the task graph, execution environment, and shared context of humans and AI agents.

Short form: the execution layer for software delivery. Design sentence: agents operate it; humans are asked only for judgment.

Category test: can a machine operate the whole loop? Plan, claim, work, record, prove, close, pick up the next item, escalate only when human judgment is genuinely needed. Being readable by agents or emitting webhooks is not sufficient.

What Commission is not

• A coding agent. No model; it never writes code.
• Another Jira. Not generic portfolio reporting, capacity planning, sprint rituals, workflow configuration or arbitrary issue taxonomies. Jira is a system of record for organisational planning; Commission is the system of record for execution truth.
• AI project management. No AI summaries presented as authoritative state, no predicted dates, no synthetic health scores, no speculative confidence indicators, no AI-generated tasks entering the system without explicit human approval.
• A metrics product. No story points, velocity, burndown, delivery forecasts, team rankings or productivity scores. Explicitly out of scope.

3 · Core product primitives

Every screen must be a view over one or more of these.

3.1 Task graph. A task is the single recursive unit of work. It may have a parent, children, dependencies, acceptance criteria, a gate, evidence, claims, notes, actors, approvals and an external system identity. There is no internal taxonomy of epic, story, subtask, card or issue. Presentation may distinguish larger parent tasks as goals; that must not create a second data model.

3.2 Ready frontier. Everything workable right now: open, not blocked by dependencies, not prevented by child completion rules, claimable. Derived at query time, never stored as mutable state.

3.3 Blocked. A derived condition — one or more dependencies unsatisfied. Never manually set or cleared, never presented as a workflow status. Always explainable: what blocks it, why the blocker is unsatisfied, what becomes unblocked if it closes.

3.4 Claim and lease. A claim is exclusive permission to work a task; a lease is its expiry boundary. Claims are atomic, expire, cannot wedge work indefinitely, and become reclaimable. The UI must distinguish owner, claimant and approver.

3.5 Gate and evidence. A gate names the evidence kinds required to close a task; evidence satisfies them. Kinds include PR, commit, test run, benchmark, deployment, approval, artifact, screenshot, external verification. The key differentiator. The UI must always preserve gate = requirement, evidence = satisfaction.

3.6 Refusal. A rejected action stating what is missing, why it cannot proceed, and the exact command that resolves it. Refusals are prompts, not errors, and render as structured guidance rather than generic failure messages.

3.7 Context bundle. Everything needed to work a task: body, acceptance criteria, dependencies, docs, prior notes, decisions, evidence, prior failed attempts, and the commands needed to finish. Agents consume it directly; humans may inspect a curated representation.

3.8 Event log. Append-only. Claims, releases, lease expiry, evidence added, approval requested and granted, refusals, sync events, closure, forced closure, actor changes, questions and answers. History is added to, never rewritten.

4 · Completion semantics

4.1 Done is a predicate, not a status. A task cannot become done because a user dragged it into a column. commission done is refused until all acceptance criteria are satisfied, all required evidence kinds are attached, evidence contains real references, child tasks are closed where required, required human approval is present, and any other gate conditions are satisfied. The refusal lists each missing requirement and the exact command that satisfies it. The dashboard fails if this distinction is not visible.

4.2 Forced closure. Possible only when policy allows. Explicitly recorded, visually distinct, included in proof tallies and task history, attributable to a human actor, never hidden behind ordinary completion styling. Forced does not mean failed — it means closure occurred without satisfying the normal predicate.

5 · Actor model

5.1 Agents claim tasks, write code, attach evidence, add notes, answer machine-resolvable questions, close what they can, leave context for future sessions, and operate through CLI, API and MCP. They do not need the dashboard.

5.2 Humans own intent, judgment and approval. That is the whole design problem. They should not be pulled into execution mechanics unless intentionally inspecting.

5.3 Dispatch split. next serves agents — what should I work on now? inbox serves humans — where is my judgment required? It returns approvals, questions, escalations, sync conflicts, finished work awaiting acceptance, stale or silent execution, policy violations and disagreements with external systems. The dashboard must be organised around inbox, not next.

6 · Why the dashboard exists

Agents already have CLI, JSON API and MCP. The dashboard exists because judgment is visual comparison work, trust must be earned visually, and some people need to observe without operating. It is the observation and judgment surface.

7 · Primary human questions

Every primary screen answers one or more.

7.1 Does anything need me? Per item: what is it, why does it require a human, what is blocked, what happens if I wait, what single action resolves it.

7.2 Can I believe what is finished? Completion, evidence, gate satisfaction, tests, PRs, commits, approvals, forced closures.

7.3 What happened while I was away? Meaningful closures, decisions, lease expiry, agent recovery, newly ready work, sync events, stalled execution, project silence.

7.4 What is the machine doing now? Secondary. Active agents, claims, lease clocks, ready frontier, blocked work, parallelism, sync state.

8 · Real data constraints

Implications: the queue is small; most tasks are closed; hierarchy is optional; dependencies may be the real structure; projects go cold; empty must feel successful; history and proof matter more than backlog volume.

9 · Product modes and project context

9.1 Categories. Work, Personal, Client, Open Source — classification, not workflow.

9.2 Execution modes. Commission-only, Jira-integrated, solo, collaborative, human-plus-agents, agents-only-except-approvals. Capability and policy differences; they must not create separate navigation or separate task pages.

9.3 Project switcher. Shows name, category, source type, attention count, optional collaborator avatars, sync state when relevant. Plus an All projects estate-level context (not a project).

9.4 Switching behaviour. Preserves the active section — Home→Home, Proof→Proof, Work→Work, Activity→Activity, Search→search scoped to the new project. Never dump the user back to Home.

9.5 Default context. Last-viewed project. All projects is deliberate, not forced.

10 · Information architecture

Primary sidebar: Home, Inbox, Proof, Work, Search, Activity. Below: Projects, Settings.

Avoid the word “Board” — it implies status columns and conventional PM behaviour.

11 · Visual direction

Use the approved dashboard mockup as the visual foundation.

11.1 Feeling. Calm, premium, modern, precise, lightweight, alive, trustworthy, effortless. Avoid enterprise heaviness, generic admin styling, Bootstrap-era card grids, kanban-first layouts, excessive pills, decorative metrics, neon glow, thick shadows, crowded metadata.

11.2 Canvas and surfaces. Soft neutral-gray page background, white cards, restrained borders, large radii, subtle depth. Never pure white as the full-page background. Cards separated by light and depth, not outlined boxes.

11.3 Typography. Drives hierarchy. The largest type on the page must be the most variable and relevant fact. Good: “6 things need your judgment.” / “Nothing needs you.” / “14 tasks completed overnight.” / “One issue is blocking 8 tasks.” Bad: project name as the largest element; static page labels dominating; nearly all text at 12–14px.

11.4 Glow and depth. Atmospheric depth, not decoration: subtle bloom around the hero graph, light diffusion behind selected surfaces, soft edge illumination, controlled shadows, slight tinted ambient light. Avoid neon halos, blurred purple blobs, heavy box-shadow glow, gradient borders, visible effect treatment. The user should feel depth before consciously noticing glow.

11.5 Colour. Primary accent purple/violet. Secondary blue, green, orange, red. Semantics: purple = primary action, current context, Commission identity; blue = informational, external link, neutral execution; green = proven, complete, healthy; orange = approval, forced, warning, Jira attention; red = urgent, unsafe, failed, severe conflict. Colour may never be the only signal.

11.6 Motion. Approval-item collapse, counter animation, project crossfade, evidence reveal, timeline extension, proof-strip fill, task movement into history. Avoid bounce, spring overshoot, scale pops, parallax, unnecessary looping. Respect reduced motion.

11.7 Illustrations. Reserved for success and empty states. Soft landscapes, minimal trees, subtle environmental depth, calm compositions, low contrast. No mascot.

12 · Global Home

Estate-level human surface. Answers what needs me across all projects, what changed, what is proven, which projects need attention.

12.1 Hero. e.g. “Good morning, Alex. / 6 things need your judgment. / The machine finished 14 tasks overnight.” The headline is the primary information; the project name is not.

12.2 Hero graph. Directly under the heading. Communicates execution rhythm, creates depth, establishes identity, shows recent movement. Atmospheric, not analytical — never labelled as a productivity chart and never implying forecasts.

12.3 Status chips. e.g. 12 proven · 2 need approval · 0 urgent · nothing else needs you.

12.4 Needs your judgment. The primary functional block, sorted by impact. Each row: title, concise reason, age, unblock count or cost, source project, primary action — Review, Approve, Answer, Resolve, Reopen, Inspect.

12.5 Proof you can trust. Total closed, proven, with tests, forced. A Git-history-style proof strip: green proven, orange forced, neutral incomplete. Below, recent proven work. About confidence, not analytics.

12.6 While you were away. Append-only summary of meaningful changes — Relay-42 closed, benchmark improved, session resumed after lease expiry, tasks became ready, Jira sync conflict detected. A compact event narrative, not a notification inbox.

12.7 Machine activity. Active agents, current task, current state, remaining lease, progress where available. Secondary.

12.8 Projects at a glance. Name, category, source, closed count, need-you count, restrained completion indicator, sync attention where relevant.

12.9 Recent completions. Horizontal Git-history-inspired sequence: task ID, compact title, commit or evidence reference, tests passed or no test required, age, actor where useful.

12.10 Execution summary. Bottom strip: ready frontier, blocked, in flight, leases, sync status. Secondary operational context.

13 · Project Home

The same model as Global Home, scoped to one project: project situation, judgment queue, proof summary, recent activity, machine activity, project-specific execution summary, sync state where relevant. Not a different design language.

14 · Empty Project Home

An empty queue is a success state. e.g. “Nothing needs you. / Everything requiring human judgment has been resolved.” Below: calm illustration, recent proof, while-you-were-away items if present, optional machine activity, link to inspect Work. Never a blank white card with “No items.”

15 · Inbox

The complete human judgment queue.

15.1 Item kinds. approval, answer required, acceptance required, sync conflict, stale execution, expired claim, forced closure review, external disagreement, permission escalation, project-level decision.

15.2 Item content. What happened, why a human is required, what is blocked, what it costs to ignore, the action that resolves it.

15.3 Sorting. Highest unblock count, then highest severity, then oldest unresolved, then project priority if available. Backend-derived.

15.4 Filters. project, kind, age, impact, actor, source, urgent only, assigned to me.

15.5 Review flow. Opening an item preserves queue context. Split view on desktop where practical, full-screen detail on mobile, next-item behaviour after resolution.

16 · Judgment Review

16.1 Approval review. Task intent, completion summary, gate requirements, attached evidence, missing evidence, prior decisions, actor, external source if applicable. Actions: Approve, Reject with reason, Reopen, Force close if permitted, Inspect full task.

16.2 Ask / Answer. The agent’s question, why it cannot safely decide, affected tasks, relevant context, prior decisions, suggested options if available. Actions: Answer, request more information, defer, cancel affected work where permitted.

16.3 Sync conflict. Commission value, external value, ownership policy, event history, consequences of each choice. Actions: keep Commission, keep Jira, reopen, intentionally diverge, retry sync.

17 · Task Detail

The strongest and most complete screen in the product.

17.1 Header. Breadcrumb or graph position, title, current state, claim, lease, owner, approval requirement, external identity. Does not begin with a metadata sidebar.

17.2 Intent. One concise sentence explaining why the task exists.

17.3 Outcome. What must be true when it is finished.

17.4 Acceptance criteria. Each criterion and whether it is satisfied.

17.5 Gate requirements. In order. Kind, status, evidence attached, exact command to satisfy if missing.

17.6 Evidence. Real references — PR, commit, test run, benchmark, deployment ID, approval. Should visually resemble trusted checks, not generic attachments.

17.7 Dependencies. Blocked by, unlocks, siblings, parent, children where relevant. Names, state and relationship — not only IDs.

17.8 Working context. Task body, linked docs, prior decisions, prior notes, failed attempts, environment notes, finish commands. Optional advanced controls: view agent context, copy as JSON, copy CLI command.

17.9 Activity timeline. Append-only. Actor, action, timestamp, references, source, sync effects. Never collapse important semantic events into generic “updated” entries.

17.10 Primary action. Changes with task state — Review evidence, Answer question, Approve, Reject, Resolve conflict, Reclaim, Cancel, Force close. Never a generic save button.

18 · Parent Task / Goal Detail

Do not introduce Epic as an internal concept. A parent task may be presented as Goal, Mission or Initiative but remains a task.

18.1 Header. Title, intent, subtree summary, human attention state, external identity if any.

18.2 Subtree summary. Backend-derived: total, closed, ready, blocked, inFlight, needsHuman, forced, withEvidence, withTests.

18.3 Child grouping. Needs You, Ready, In Flight, Blocked, Recently Closed. Not a kanban board by default.

18.4 Dependency bottlenecks. Critical blocker, number of tasks affected, immediate chain, action required.

18.5 Proof rollup. Evidence coverage across the subtree — tally, grouped kinds, exceptions, forced items, drill-down. Not a flat list of hundreds of evidence rows.

18.6 Completion gate. What still prevents the parent task itself from closing.

19 · Work

For observing execution.

19.1 Sections. Ready frontier, in flight, blocked, parallel batches, expired or expiring leases, recently closed, cancelled.

19.2 Default view. Compact grouped list. Not status columns.

19.3 Alternate views. Dependency graph, hierarchy tree, agent allocation, timeline where useful — alternate inspection modes.

20 · Dependency Graph

Must support projects with many edges. Requirements: focus on one task, show upstream blockers, show downstream unlocks, expand progressively, zoom and pan, collapse unrelated branches, label every relationship, provide an accessible list alternative. Do not render the entire project graph by default. Start from selected task, current bottleneck, ready frontier or human attention item.

Core provides immediate blockers, immediate dependents, dependency chain, cycle detection, bottleneck rank and unblock count. The UI must not compute graph semantics.

21 · Proof

The trust surface.

21.1 Project summary. Total closed, with evidence, with tests, forced, awaiting acceptance, incomplete-gate exceptions.

21.2 Recent proven work. Compact list: task, actor, evidence kinds, age, forced flag.

21.3 Exceptions. Prioritise forced closures, missing evidence, invalid references, stale external evidence, approvals later revoked, tasks closed under older gate policies where relevant.

21.4 Volume handling. At high volume: group by day, group by gate type, exception-first, summarise healthy work, allow drill-down. Not hundreds of identical rows.

22 · Proof Detail

For one task: each gate requirement, corresponding evidence, evidence reference, actor, timestamp, verification state, closure actor, approval history, forced status, external sync effect.

23 · Activity

The append-only event log.

23.1 Filters. project, task, actor, event kind, source, date, human-only, agent-only, sync-only.

23.2 Watermark. Per-person. “Since you last looked” advances only when explicitly acknowledged. Rendering the page must not mutate the watermark.

23.3 Event presentation. Human-readable but traceable, with advanced raw details for debugging.

24 · Search

Across task title, body, notes, decisions, evidence, actors, events, Jira keys, commit refs, PR refs. Global and project-scoped, keyboard navigation, grouped results, filters, direct actions.

25 · Jira integration model

The hardest part is ownership, not transport. Commission must define which system owns which facts.

25.1 Recommended default. Jira planning, Commission execution.

• Jira owns planning facts: external key, title, description, priority, labels, assignee or team ownership, issue type, roadmap placement, external status projection.
• Commission owns execution facts: dependencies used for dispatch, ready frontier, claims, leases, gates, evidence, refusals, asks, answers, agent notes, execution history, the actual completion predicate.

25.2 Jira is a projection of execution state. Do not map every Commission state into Jira.

Inside Commission, always show the real state. Jira status is an external representation.

25.3 Sync policies. Presets: Jira planning, Commission execution (default for teams); Jira mirror (read Jira, suggest write-backs, require approval before mutating external state); Commission primary (Commission owns most fields and updates Jira for organisational visibility). Allow field-level overrides after preset selection.

25.4 Field ownership UI. Every externally synced field exposes owner, direction, last sync, pending change, conflict state.

25.5 Sync status. Connected site, Jira project, last successful sync, pending writes, failed writes, auth state, retry state, rate-limit state, conflicts.

25.6 Conflict handling. Conflicts are first-class inbox items. Examples: Jira says Done but Commission refuses because evidence or approval is missing; Commission says Done but Jira was moved back to In Progress. Actions: keep Commission, keep Jira, reopen in Commission, restore Jira, leave intentionally divergent. Never silently last-write-win on semantic conflicts.

25.7 Offline behaviour. Execution continues when Jira is unavailable. e.g. “Jira sync delayed. Work is continuing locally. 7 updates pending.” The execution layer cannot stop because Jira is down.

25.8 Jira identity on Task Detail. Jira key, type, sync state, ownership summary, last sync, conflict indicator. Do not reshape the task page into a Jira issue layout.

26 · Collaboration model

Always separate owner, current claim and approval authority. Show presence only where it changes behaviour — “Sam is reviewing now”, “Claude Code holds the claim”, “Maya answered 3m ago”. Avoid green-dot social presence throughout the app.

27 · Roles and permissions

Roles: Owner, Admin, Approver, Contributor, Viewer, Agent.

Permissions: view project, create task, edit task, change planning fields, change execution policy, approve, force close, cancel, manage Jira, manage users, manage agent credentials.

A human approval must never be grantable by an agent. Enforced in core.

28 · Planning and task creation

28.1 Create task. intent, outcome, acceptance criteria, parent, dependencies, gate requirements, owner, approval policy, external Jira mapping, notes. Advanced fields hidden by default.

28.2 Bulk creation. Pasted structured work, imported JSON or text, preview, hierarchy validation, dependency validation, duplicate detection, final confirmation.

28.3 Planning flow. A human may state intent; Commission may propose a task graph. Generated structure is visibly provisional until accepted. Never silently create authoritative work from generated text.

29 · Notifications

29.1 Centre. Human judgment required, approval completed, sync conflict, quiet or stalled execution, claim expiry, project summary, failed external write.

29.2 Preferences. Per-project controls, work vs personal schedules, immediate vs digest, in-app, email, future integrations.

30 · Mobile

Not a miniature desktop dashboard. Primary workflows: review inbox, approve, answer an ask, inspect proof, inspect task, search, view project situation, review notifications. Avoid full dependency graph, dense execution matrix, broad project administration. Focused single-column flows, sticky primary action, clear evidence grouping, optional swipe gestures, excellent back-stack behaviour.

31 · Tablet

Collapsible sidebar, two-column review, project Home, task detail, Proof, Work list, light graph inspection.

32 · Design system

32.1 Foundations. Tokens for background, surfaces, borders, text, muted text, accent, success, warning, danger, spacing, radius, shadow, motion, z-index, focus ring.

32.2 Core components. AppShell, Sidebar, TopBar, ProjectSwitcher, SituationHeader, HeroGraph, StatusChip, Card, SectionHeader, EmptyState, Button, IconButton, Input, Select, SearchField, FilterBar, Tabs, Dialog, Drawer, Tooltip, Toast, CommandPalette, Timeline, Avatar, Badge, ProgressBar.

32.3 Domain components. JudgmentItem, JudgmentQueue, ProofSummary, ProofStrip, EvidenceRow, GateChecklist, GateRequirement, RefusalPanel, ClaimBadge, LeaseTimer, ActorBadge, TaskRow, TaskHeader, DependencyNode, DependencySummary, SubtreeSummary, ProjectGlanceRow, MachineActivityRow, SyncBadge, SyncStatusPanel, ConflictPanel, JiraIdentity, ActivityEvent, CompletionNode.

32.4 Component states. Every component specifies default, hover, focus, active, selected, disabled, loading, error, read-only and permission-denied.

33 · Required screens

Core (1–12): Global Home, Project Home, Inbox, Judgment Review, Task Detail, Parent Task / Goal Detail, Work, Dependency Graph, Proof, Proof Detail, Activity, Search.

Project and team (13–19): Project Switcher, Project Creation, Project Settings, Members, Member Detail, Agent Detail, Approval Policy Editor.

Jira (20–29): Connect Jira, Choose Site / Project, Import Preview, Sync Policy, Field Ownership, Status Mapping, Sync Status, Sync History, Conflict Resolution, Reconnect / Auth Failure.

Planning (30–33): Create Task, Edit Task, Bulk Task Creation, Planning Proposal Review.

System (34–45): Notifications Centre, Notification Preferences, User Settings, Authentication, Invite Acceptance, Onboarding, CLI / MCP Connection, API Tokens, Audit, Backup, Restore, Upgrade / Migration.

Responsive variants (46–51): Mobile Inbox, Mobile Judgment Review, Mobile Task Detail, Mobile Proof, Tablet Project Home, Tablet Task Detail.

34 · Required global states

Every major screen designs and implements:

34.1 Empty. nothing needs you, no tasks, no proof, no activity, no collaborators, no Jira connection, no search results.

34.2 Loading. initial app load, project switch, route transition, sync, graph expansion, event pagination.

34.3 Error. SQLite unavailable, server disconnected, Jira auth expired, partial sync failure, invalid evidence reference, permission denied, corrupted external response.

34.4 Offline / stale. local data available, external data stale, pending writes, retry scheduled, execution continuing locally.

34.5 Permission. read-only, cannot approve, cannot edit Jira-owned field, cannot view project, agent blocked from human action.

34.6 Destructive confirmation. force close, reopen, cancel, disconnect Jira, archive project, remove member, delete project, revoke token.

35 · Backend contracts

The frontend must not re-implement domain logic. Core exposes composed, authoritative structures.

type Situation = {
  text: string
  mood: "clear" | "attention" | "alarm"
  figures: Array<{ label: string; value: number | string }>
  reasonCodes: string[]
}                                   // text renders verbatim

type InboxItem = {
  id: string; kind: string; projectId: string; taskId?: string
  title: string; what: string; whyHuman: string; costOfWaiting: string
  command: string; ageSeconds: number; unblockCount: number
  severity: "normal" | "attention" | "urgent"; primaryAction: string
}

type ProvenDoneSummary = {
  closed: number; withEvidence: number; withTests: number
  forced: number; items: ProvenDoneItem[]
}

type DoneGate = {
  taskId: string; canClose: boolean
  requirements: Array<{
    kind: string; label: string; met: boolean
    evidence?: EvidenceRef[]; command?: string
  }>
}

type WorkView = {
  ready: TaskSummary[]; parallelBatches: TaskSummary[][]
  blocked: BlockedTask[]; inFlight: InFlightTask[]
  recentlyClosed: TaskSummary[]; recentlyCancelled: CancelledTask[]
}

type Watermark = {
  userId: string; projectId?: string; cursor: string; acknowledgedAt: string
}

type SubtreeRollup = {
  total: number; closed: number; ready: number; blocked: number
  inFlight: number; needsHuman: number; withEvidence: number
  withTests: number; forced: number
}

type DependencyGraph = {
  focusTaskId: string; nodes: DependencyNode[]; edges: DependencyEdge[]
  upstreamDepth: number; downstreamDepth: number; cycles: string[][]
  bottlenecks: Array<{ taskId: string; blockedCount: number }>
}

type SyncStatus = {
  provider: "jira"; connected: boolean; lastSuccessAt?: string
  pendingWrites: number; failedWrites: number; stale: boolean
  authState: "ok" | "expired" | "missing"; conflicts: number
}

36 · Technical constraints

• Ships as a single binary plus SQLite.
• No runtime CDN dependency; no external static directory; assets and fonts compiled in.
• Runs on localhost by default; may also serve a small team with accounts.
• Current frontend is Preact + Tailwind, but the architecture may change. The no-runtime-dependency rule remains.
• Light and dark are first-class; light is default.
• The UI never computes business facts core already derives.
• Composed server sentences render verbatim.
• No forecasts, velocity, burndown or health scores.
• Colour is never the only signal.
• Agents can never approve.

37 · Dark theme

Preserves the same hierarchy. May use deeper surfaces, restrained atmospheric glow, luminous proof accents, richer contrast. Must not become cyberpunk, neon, gaming UI or overly glossy. Light and dark should feel like the same product.

38 · Accessibility

Keyboard-first navigation, visible focus, semantic HTML, screen-reader labels, high contrast, reduced motion, colour-independent statuses, accessible graph alternative, accessible lease timers, no information hidden only in hover, mobile target sizes, proper live regions for queue updates.

39 · Performance

Project switch preserves the shell, route-level code splitting where useful, no blocking animation, virtualised large event logs, progressive graph expansion, server-composed summaries, cached stable reference data, optimistic UI only where domain-safe, explicit pending state for external sync.

40 · Analytics and telemetry

Acceptable operational telemetry: page latency, error rate, sync failure rate, interaction completion, accessibility failures, dropped events, backend timing.

Avoid worker productivity scoring, user ranking, velocity dashboards and opaque engagement metrics shown to users.

41 · Implementation order

1. Foundations — design tokens, app shell, sidebar, project switcher, core cards, typography hierarchy, motion primitives, empty states.
2. Core human loop — Global Home, Project Home, Inbox, Judgment Review, Mobile Judgment Review.
3. Trust — Task Detail, Gate Checklist, Evidence components, Proof, Proof Detail, forced-closure treatment.
4. Execution observation — Work, Machine Activity, Ready Frontier, Claims and Leases, Dependency Summary, Dependency Graph.
5. Hierarchy — Parent Task / Goal Detail, subtree rollups, proof rollups, bottleneck summaries.
6. History — Activity, watermark, Search, recent completions.
7. Collaboration — Members, roles, approval policies, agent detail, presence.
8. Jira — connection flow, import preview, sync policy, field ownership, status mapping, sync status, conflict resolution, offline writes.
9. System — notifications, settings, authentication, tokens, audit, backup/restore, upgrade/migration.
10. Polish — tablet, mobile, dark theme, accessibility pass, performance pass, motion pass, visual QA.

42 · Build principles

42.1 Reuse domain components. Compose from JudgmentItem, ProofSummary, GateChecklist, EvidenceRow, TaskRow, Timeline, SyncBadge, ConflictPanel, SituationHeader — not bespoke markup per screen.

42.2 Backend before UI workarounds. When the UI needs a derived fact, add it to core. Never compute subtree summary, dependency chain, proof coverage, ready state, unblock count, gate status, sync conflict severity or situation text in the frontend.

42.3 Preserve vocabulary. task, ready frontier, blocked, claim, lease, gate, evidence, refusal, ask, answer, actor. Do not rename casually.

42.4 Avoid Jira drift. Every Jira-backed experience must still feel like Commission. External metadata is attached to the Commission model; it does not replace it.

43 · Validation against real projects

Every major screen is tested with Commission (111/105/2, dependency-heavy), GulfWeather (156/121/9, meaningful parents) and Steer (26/1/5, Jira-backed with disagreement).

Also: empty project; one-task project; project with no activity for 30 days; project with 100+ proof rows; project with 100+ dependency edges; project with one human and several agents; project with many collaborators; Jira unavailable; agent claim expired; task force-closed; all-project inbox empty; a goal broken into workstreams, one blocked behind another.

44 · Acceptance criteria

Product understanding. A first-time user understands: agents do the execution, humans provide judgment, done is verified, evidence is attached, the system remembers, Jira is optional and external.

Dashboard. Home answers what needs me, what changed, what is proven, what is happening now.

Task detail. A user understands why the task exists, what success means, what remains, what proves completion, who is working, what blocks it.

Proof. A user can believe or challenge a completion without leaving Commission.

Jira. A user can tell which system owns each fact, whether sync is healthy, why a conflict exists, and what each resolution will do.

Mobile. A user can approve, answer, inspect proof and resolve high-value inbox items.

Visual quality. Calm, premium, fresh, modern, light, responsive, intentional. It does not feel like Jira, Linear, Asana, Trello, a generic admin dashboard or a status board.

45 · Final product standard

Commission does not write your code and does not replace your judgment; it is the layer everything else runs on.

The dashboard is where the judgment half of that sentence happens. Its job is to make the human confident that machines did the work correctly, request the few decisions that genuinely belong to a person, preserve execution truth, remain calm when nothing needs attention, and otherwise stay out of the way. Everything else is secondary.