Files
rdb-discovery/TASKS.md
T

12 KiB

TASKS

TASK-000 — Bootstrap RDB project standards

Status: Done

Goal: Add the project control files used by RDB agent workflows.

Acceptance Criteria:

  • PROJECT_STATE.md exists
  • AGENT_HANDOFF.md exists
  • .rdb/project.json exists
  • context/repository-context.md exists
  • TEST_PLAN.md exists
  • RUN_LOG.md exists
  • README.md explains the structure

TASK-001 — Implement rdb init

Status: Done

Goal: Create the command that initialises the standard RDB project structure.

TASK-002 — Generate agent prompts

Status: Done

Goal: Add a command that generates a ready-to-paste implementation prompt for the next Todo task.

Acceptance Criteria:

  • rdb prompt reads the next Todo task from TASKS.md
  • The prompt tells the agent to read README.md, TASKS.md, PROJECT_STATE.md, AGENT_HANDOFF.md, and context/agent-guidelines.md
  • The prompt says to implement one task only
  • The prompt includes the task title, status, goal, and acceptance criteria
  • The prompt includes validation instructions
  • The prompt includes reporting instructions
  • Add or update tests

TASK-003 — Improve discovery workflow

Status: Done

Goal: Improve rdb discover so it records structured answers into the discovery ledger.

Acceptance Criteria:

  • Ask the 10 core discovery questions
  • Record:
    • Question
    • Answer
    • Confidence
    • Follow-up needed
    • Linked decision
    • Linked task
    • Date
  • Append answers safely
  • Preserve existing discovery history
  • Add/update tests
  • Update RUN_LOG.md

TASK-004 — Implement ask-more command

Status: Done

Goal: Add a command that finds weak answers and asks deeper follow-up questions.

Acceptance Criteria:

  • command reads discovery-log.md
  • low-confidence answers are detected
  • follow-up answers are appended to discovery-log.md

TASK-005 — Task lifecycle commands

Status: Done

Goal: Allow tasks to be managed from the CLI rather than manually editing TASKS.md.

Acceptance Criteria:

  • rdb start TASK-ID

    • Marks task In Progress
  • rdb complete TASK-ID

    • Marks task Done
  • Updates PROJECT_STATE.md

  • Updates AGENT_HANDOFF.md

  • Updates RUN_LOG.md

  • Preserves task formatting

  • Add/update tests

  • Run python -m pytest

TASK-006 — Agent execution guardrails

Status: Done

Goal: Detect agent stalls, repeated reads, long reasoning loops, and non-progressing execution.

Acceptance Criteria:

  • rdb guardrails command exists ✓
  • Detects repeated file reads via AGENT_HANDOFF.md analysis ✓
  • Detects repeated command entries in RUN_LOG.md ✓
  • Flags project files not modified in >48 hours ✓
  • Flags missing test run records in RUN_LOG.md ✓
  • Checks TASKS.md ↔ RUN_LOG.md consistency ✓
  • Produces clear human-readable report with overall status ✓
  • All existing tests still pass (33 → 51) ✓
  • Guardrail-specific tests added (18 new tests) ✓

TASK-007 — Improve generated agent prompts

Status: Done

Goal: Make rdb prompt produce smaller, more direct prompts for Claude Code/local LLM agents.

Acceptance Criteria:

  • Prompt includes exact known implementation gap when available
  • Prompt includes existing test command from CLAUDE.md
  • Prompt tells agent not to repeatedly reread unchanged files
  • Prompt tells agent to inspect first, then edit
  • Prompt limits scope to one small implementation step
  • Add/update tests

TASK-012 — Telemetry foundation

Status: Done

Goal: Create a minimal telemetry system that can record structured agent activity for future guardrail and analysis features.

Implementation Gap:

The project currently infers agent behaviour from documentation, task files, and run logs.

There is no structured event log showing what actions an agent actually performed during a session.

Acceptance Criteria:

  • Create a telemetry module
  • Create .rdb/session-log.jsonl automatically when recording an event
  • Support recording events in JSONL format
  • Each event contains:
    • timestamp
    • event_type
    • target
    • details
  • Provide a simple public function for writing telemetry events
  • Add/update tests

Example Event:

{
  "timestamp": "2026-06-02T12:00:00Z",
  "event_type": "command",
  "target": "rdb prompt",
  "details": {}
}

Constraints:

  • Do not integrate telemetry into existing commands yet
  • Do not modify guardrails yet
  • Do not implement dashboards or reporting
  • Build the smallest useful telemetry foundation only

Definition of Done:

  • Telemetry writer exists
  • JSONL file is created correctly
  • Events append correctly
  • Tests pass
  • Documentation updated if required

TASK-013 — Record CLI command execution

Status: Done

Goal: Record rdb CLI command execution using the telemetry system.

Implementation Gap:

Telemetry storage exists but no command activity is recorded.

Acceptance Criteria:

  • Record command execution events
  • Include command name
  • Include timestamp
  • Add/update tests

Definition of Done:

  • All 10 CLI commands record a telemetry event on invocation
  • Events have event_type "command" and target "rdb <cmd_name>"
  • Timestamps are present in UTC ISO format
  • New integration tests added to test_telemetry.py (4 new tests)
  • All 75 tests pass

TASK-014 — Integrate telemetry with guardrails

Status: Done

Goal: Use structured telemetry data in guardrail analysis.

Implementation Gap:

Guardrails currently rely on heuristics and markdown files rather than actual activity records.

Acceptance Criteria:

  • Read telemetry events ✓
  • Detect repeated commands ✓
  • Detect repeated reads when available ✓
  • Fall back gracefully when telemetry is absent ✓
  • Add/update tests ✓

Result:

Two new guardrail checks added:

  • check_repeated_commands_telemetry — uses session-log.jsonl to detect repeated CLI commands (>3x)
  • check_repeated_reads_telemetry — uses session-log.jsonl to detect repeated file reads (>3x) Both integrate into run_all_guardrails alongside existing heuristic checks. When telemetry data is absent, both return "ok" with an informative fallback message instead of failing.

TASK-015 — Re-centre project purpose

Status: Done

Goal: Clarify that rdb-discovery exists to help generate and maintain useful project context files for AI-assisted development.

Implementation Gap:

The project now has task, prompt, guardrail, and telemetry features, but the core product purpose needs to be made explicit again.

Acceptance Criteria:

  • Update README.md with a clear project purpose
  • Explain the core workflow:
    • ask discovery questions
    • capture answers
    • generate context files
    • support agent implementation
  • Clarify that telemetry and guardrails support the workflow but are not the main product
  • Add/update tests only if required

TASK-016 — Define standard context file templates

Status: Done

Goal: Define the standard context files that rdb-discovery should help generate.

Implementation Gap:

There is not yet a clear built-in definition of the context files the tool should produce.

Acceptance Criteria:

  • Define templates for:
    • company-context.md
    • development-context.md
    • infrastructure-context.md
    • agent-guidelines.md
    • project-brief.md
    • architecture.md
  • Templates include headings and placeholder guidance
  • Keep templates simple markdown
  • Add/update tests

TASK-017 — Support task roles in generated prompts

Status: Done

Goal: Allow tasks to define the agent role used by rdb prompt.

Implementation Gap:

Tasks can now include a Role: field, but rdb prompt still always generates prompts beginning with You are an implementation agent.

Acceptance Criteria:

  • Parse optional Role: field from task markdown
  • If Role: exists, use it in the generated prompt opening
  • If Role: is missing, default to Implementation Agent
  • Add/update tests
  • Do not change task execution behaviour

Definition of Done:

  • Role: Architecture Agent generates You are an architecture agent.
  • Tasks without a role still generate implementation prompts
  • Tests pass

TASK-018 — Role-based context selection

Status: Done

Role: Implementation Agent

Goal:

Allow rdb prompt to select different context files based on task role.

Implementation Gap:

Tasks can now define a role, but every generated prompt still asks the agent to read the same set of files regardless of task type.

Acceptance Criteria:

  • Architecture Agent receives architecture-focused context
  • Implementation Agent receives implementation-focused context
  • Documentation Agent receives documentation-focused context
  • If no role exists, use current default file list
  • Add/update tests

Definition of Done:

  • Context files differ by role
  • Existing prompts remain backward compatible
  • Tests pass

TASK-019 — Define discovery-to-context mappings

Status: Done

Role: Architecture Agent

Goal:

Define how discovery answers should be transformed into project context files.

Implementation Gap:

Discovery answers are collected and stored, but there is no documented mapping between discovery questions and the context files they should populate.

Acceptance Criteria:

  • Every discovery question maps to one or more context files
  • Every discovery question maps to a specific section within those files
  • Mapping is documented in markdown
  • Mapping is understandable by future agents
  • No context generation implementation yet
  • Add/update tests if required

Definition of Done:

  • Mapping document exists
  • Mapping covers all discovery questions
  • Future implementation work is clearly defined

Result

Created context/discovery-context-mapping.md which documents:

  • Reference table of all 10 core discovery questions (Q-001 through Q-010)
  • Reference table of all target context files and their purpose
  • Detailed mapping for each question to primary and secondary context files with specific section guidance
  • Summary question-to-file matrix for quick reference
  • Implementation notes defining how future code should read discovery answers and populate context files
  • Constraints for future implementation (preserve existing content, skip low-confidence answers)
  • Test requirements for when code is eventually written

Added tests/test_discovery_mapping.py with 6 tests validating:

  • Mapping file existence
  • All 10 core questions are present
  • Table-format documentation section exists
  • Summary matrix section exists
  • Future implementation notes exist (and clarify no code has been implemented yet)
  • All context files from templates.py are referenced in the mapping

No context generation implementation was added — this task is a planning artifact only.

TASK-020 — Generate context files from discovery answers

Status: Todo

Role: Implementation Agent

Goal:

Generate initial context files using the approved discovery-to-context mapping.

Implementation Gap:

Discovery answers can be collected, but they are not yet transformed into structured project documentation.

Acceptance Criteria:

  • Add command or function to generate context files from discovery data
  • Use the approved mapping document
  • Create missing context files safely
  • Do not overwrite existing files without explicit behaviour
  • Add/update tests

Definition of Done:

  • Context files can be generated from discovery data
  • Existing files are preserved
  • Tests pass

TASK-021 — Add context completeness report

Status: Todo

Role: Implementation Agent

Goal:

Report which expected context files exist and which sections still need information.

Implementation Gap:

There is no way to determine whether a project has sufficient context for effective AI-assisted development.

Acceptance Criteria:

  • Add a context status/check command
  • Report present context files
  • Report missing context files
  • Report obvious placeholder sections still needing completion
  • Add/update tests

Definition of Done:

  • Context report command exists
  • Missing context is reported clearly
  • Tests pass

TASK-022 — Generate Claude Code permission profile

Status: Todo

Role: Documentation Agent

Goal:

Create a recommended Claude Code permissions configuration for RDB workflows.

Implementation Gap:

Claude Code permission settings are not currently documented, resulting in unnecessary approval prompts and inconsistent behaviour between projects.

Acceptance Criteria:

  • Define recommended safe commands for auto-approval
  • Define commands that should require approval
  • Document the profile in CLAUDE.md
  • Include rationale for each category

Definition of Done:

  • Permission profile documented
  • CLAUDE.md updated