Docs
AI Docs
Crystal Agents
Sprint Tickets

Sprint Tickets

Sizing assumption:

  • 2-week sprints
  • tickets should be small enough for one developer to finish in 0.5 to 2 days
  • each ticket should produce a visible artifact, not just “progress”

Sprint 1 - Project Skeleton

Goal: establish the repo, runtime, and execution boundaries.

Status: Done

Tickets

  • T1: Create the Python project scaffold and package layout.
  • T2: Define shared runtime models for tasks, runs, agents, workflows, and tools.
  • T3: Add Dockerfile and Docker Compose for local execution.
  • T4: Add a CLI entrypoint for starting a run.
  • T5: Add structured run logging and run artifact folders.

Acceptance Criteria

  • The repo has a consistent top-level structure.
  • A CLI command can start a placeholder run and write artifacts to disk.
  • Logs and run outputs are created in predictable locations.

Sprint 2 - Core Orchestration MVP

Goal: route one request through orchestrator, workflow, agents, and tools.

Status: Done

Tickets

  • T6: Implement the orchestrator shell and task routing contract.
  • T7: Implement the minimal workflow runner with sequential steps.
  • T8: Add base agent classes and stubs for CEO, Developer, Tester, Research, and Content.
  • T9: Add base tool classes and stubs for repo read, repo write, test runner, and web search.
  • T10: Implement the first two workflows: feature spec generation and content drafting.

Acceptance Criteria

  • The orchestrator can select a workflow based on input type.
  • Workflow steps run in order and produce stored outputs.
  • Agent and tool calls are visible in logs.

Sprint 3 - Safety and Control

Goal: make the system safe enough for real work.

Status: Done

Tickets

  • T11: Add role-based tool allowlists.
  • T12: Add approval gates for risky actions.
  • T13: Add audit logs for tool usage and approval decisions.
  • T14: Add tests for blocked actions and denied tools.

Acceptance Criteria

  • Unapproved risky actions do not execute.
  • Denied tools are blocked by role.
  • The system records who requested and approved each sensitive action.

Sprint 4 - Operational Expansion

Goal: add the next most valuable business workflows.

Status: Done

Tickets

  • T15: Add Reviewer, DevOps, Ads Manager, Sales Assistant, SEO, and Analytics agent stubs.
  • T16: Add workflows for lead follow-up and campaign creation.
  • T17: Add workflows for bug triage and release preparation.
  • T18: Add workflows for customer reporting and proposal generation.
  • T19: Add reusable workflow templates and shared output formats.

Acceptance Criteria

  • At least one workflow for sales, marketing, and ops runs end to end.
  • Outputs follow a consistent format and are reviewable by a human.

Sprint 5 - Operator Experience

Goal: reduce friction for daily use.

Status: Done

Tickets

  • T20: Add a basic web dashboard shell.
  • T21: Add run history browsing and filters.
  • T22: Add approval queue views.
  • T23: Add daily and weekly summary reports.

Acceptance Criteria

  • A user can review tasks and run results without opening raw logs.
  • Pending approvals are visible in one place.

Sprint 6 - App-Managed Scheduler

Goal: run allowlisted bash scripts on schedule with history and approvals.

Status: Done

Tickets

  • T24: Add scheduler config models and cron parsing.
  • T25: Add scheduler CLI commands for listing and running due jobs.
  • T26: Add approval-gated scheduled job execution and history logging.
  • T27: Add a scheduler dashboard page and coverage tests.

Acceptance Criteria

  • The app can list configured jobs and run due jobs from the CLI.
  • Allowlisted scripts execute only from approved roots.
  • Pending approvals appear in the dashboard and in approval logs.
  • Scheduler runs write history and artifacts that can be reviewed later.

Later Backlog

  • model routing by task type
  • optional retrieval search over past runs
  • richer observability and step timing
  • reusable memory layers for campaigns, product, and feedback
  • weekly reporting automation

Release Notes

  • v0.1 includes the orchestrator, first workflows, approval flow, dashboard shell, report generation, and the first operational workflows.
  • v0.2 includes config-driven Telegram notifications, model provider selection, and reusable workflow templates with shared output formats.
  • v0.3 includes the app-managed scheduler, allowlisted bash scripts, approval-gated scheduled jobs, and scheduler history in the dashboard.
Security FindingsSteps to Set Up Scheduled Jobs