CI faalde sinds #191 (docs cleanup) op pre-existing broken links: - docs/old/ bevat archief-docs met by-design stale paden - docs/plans/PBI-79*, M9*, M11* hadden geprojecteerde paden naar ../backlog/index.md (verplaatst naar docs/old/backlog/) en naar app-bestanden die nooit met de juiste relatieve prefix waren geschreven - docs/adr/0000* verwees naar docs-restructure-ai-lookup.md (verplaatst) - docs/glossary.md verwees naar /docs/backlog/index.md (verplaatst) Fixes: - scripts/check-doc-links.mjs: skip docs/old/ recursief - Move docs/plans/{PBI-79,M9,M11}*.md → docs/old/plans/ (allemaal merged PBIs; plans waren historisch) - docs/adr/0000-record-architecture-decisions.md: update pad naar archief - docs/glossary.md: verwijder dode "backlog index"-link Verificatie: `npm run docs:check-links` → ✓ All doc links valid (105 files) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
68 lines
5.3 KiB
Markdown
68 lines
5.3 KiB
Markdown
---
|
|
title: "Scrum4Me — Glossary"
|
|
status: active
|
|
audience: [ai-agent, contributor]
|
|
language: en
|
|
last_updated: 2026-05-08
|
|
when_to_read: "When you encounter a domain term and need its canonical definition and the doc where it is specified."
|
|
---
|
|
|
|
# Scrum4Me — Glossary
|
|
|
|
Domain terms used across Scrum4Me docs, code, and MCP tooling.
|
|
|
|
## agent worker
|
|
|
|
A Claude Code session that has registered itself as a `ClaudeWorker` record and polls the job queue via `mcp__scrum4me__wait_for_job`. The NavBar counts active workers by `last_seen_at < now() - 15s`. See [MCP integration runbook](./runbooks/mcp-integration.md).
|
|
|
|
## ClaudeJob
|
|
|
|
A row in the `claude_jobs` table — the queue from which agents claim work atomically (`FOR UPDATE SKIP LOCKED`). Distinguished by `kind` (`TASK_IMPLEMENTATION`, `IDEA_GRILL`, `IDEA_MAKE_PLAN`, `PLAN_CHAT`, `SPRINT_IMPLEMENTATION`) and tracked through `status` (`QUEUED → CLAIMED → RUNNING → DONE/FAILED/CANCELLED/SKIPPED`). See [data-model](./architecture/data-model.md) and [MCP integration runbook](./runbooks/mcp-integration.md).
|
|
|
|
## claude-question
|
|
|
|
A pending question posted by an agent (via `mcp__scrum4me__ask_user_question`) to a human user, stored in the `claude_questions` table. The user answers in the UI; a PostgreSQL `LISTEN/NOTIFY` trigger pushes the answer back to the waiting agent. See [architecture: claude-question-channel](./architecture/claude-question-channel.md) and [ADR-0007](./adr/0007-claude-question-channel-design.md).
|
|
|
|
## demo-token
|
|
|
|
An API token whose owning user has `isDemo = true`. All write operations are blocked at three layers: the `proxy.ts` middleware, individual server actions, and disabled UI buttons. See [architecture: auth and sessions](./architecture/auth-and-sessions.md) and [ADR-0006](./adr/0006-demo-user-three-layer-policy.md).
|
|
|
|
## demo-user
|
|
|
|
A preconfigured read-only account used for public showcase. Shares product data with the main account but cannot create, update, or delete anything. See [architecture: auth and sessions](./architecture/auth-and-sessions.md).
|
|
|
|
## Idea
|
|
|
|
A user-scoped idea captured before it becomes a PBI. An idea is first _grilled_ via an interactive Q&A loop (`IDEA_GRILL` job → `grill_md`), then materialized through a deterministic plan (`IDEA_MAKE_PLAN` job → `plan_md`) into a PBI with stories and tasks. Replaced the legacy `todos` table in M12. Status enum: `DRAFT | GRILLING | GRILL_FAILED | GRILLED | PLANNING | PLAN_FAILED | PLAN_READY | PLANNED`. See [data-model](./architecture/data-model.md) and the [M12 plan](./plans/M12-ideas.md).
|
|
|
|
## MCP-job
|
|
|
|
Synonym for **ClaudeJob** — used in agent-facing docs because Claude Code consumes the queue through MCP tools. An agent claims a job atomically via `mcp__scrum4me__wait_for_job` and reports completion via `mcp__scrum4me__update_job_status`. See [MCP integration runbook](./runbooks/mcp-integration.md).
|
|
|
|
## PBI (Product Backlog Item)
|
|
|
|
The second level of the work hierarchy: `Product → PBI → Story → Task`. A PBI groups related stories under a single theme or capability. Status enum: `READY | BLOCKED | FAILED | DONE`. Has a stable `code` (`PBI-N`) per product. Do not use "Epic", "Feature", or "Issue" as synonyms.
|
|
|
|
## Solo Panel
|
|
|
|
The single-user planning screen that shows all PBIs and stories for one product in a split-pane drag-and-drop layout. Contrast with the Sprint board (team-facing). See [functional spec — Solo Panel](./specs/functional.md).
|
|
|
|
## Sprint
|
|
|
|
A time-boxed iteration with a `sprint_goal` and a stable `code` (`SP-N`) per product. A product can hold multiple sprints simultaneously (PBI-63) — `OPEN` is not exclusive; the sprint-switcher in the product header lets the user pick which sprint to plan against. Status enum: `OPEN | CLOSED | ARCHIVED | FAILED`. Stories enter `IN_SPRINT` when added to a sprint via `sprint_id`. See [data-model](./architecture/data-model.md).
|
|
|
|
## SprintRun
|
|
|
|
A single execution of the SPRINT_IMPLEMENTATION flow against one Sprint. Tracked in `sprint_runs` with status `QUEUED | RUNNING | PAUSED | DONE | FAILED | CANCELLED`, optional `pause_context` for resume, and a chain via `previous_run_id` for retries. The frozen scope-snapshot per run lives in `sprint_task_executions`. See [sprint execution modes](./architecture/sprint-execution-modes.md).
|
|
|
|
## Story
|
|
|
|
The third level of the work hierarchy: `Product → PBI → Story → Task`. A Story has acceptance criteria, an optional `assignee_id` (Solo-bord claim), a stable `code` (`ST-N`) per product, and a status (`OPEN | IN_SPRINT | DONE | FAILED`). See [functional spec](./specs/functional.md).
|
|
|
|
## Task
|
|
|
|
The leaf level of the work hierarchy: `Product → PBI → Story → Task`. A Task has an `implementation_plan`, a stable `code` (`T-N`) per product, a `status` (`TO_DO | IN_PROGRESS | REVIEW | DONE | FAILED | EXCLUDED`), `verify_only` and `verify_required` flags, and an optional `repo_url` override. API exposes status as lowercase (`todo | in_progress | review | done | failed | excluded`). See [data-model](./architecture/data-model.md) and [ADR-0004](./adr/0004-status-enum-mapping.md).
|
|
|
|
## verify_result
|
|
|
|
The agent's outcome of a verification pass (`ALIGNED | PARTIAL | EMPTY | DIVERGENT`). Combined with the task's `verify_required` threshold (`ALIGNED | ALIGNED_OR_PARTIAL | ANY`) it determines whether a job's claim of "done" is accepted by the gate. See [agent-flow-pitfalls runbook](./runbooks/agent-flow-pitfalls.md).
|