Skip to main content

Workflow

Phonton starts with the engineering loop, not chat.

flowchart LR
  Goal["Goal"] --> Plan["Plan preview"]
  Plan --> Context["Context manifest"]
  Context --> Work["Diff-only workers"]
  Work --> Verify["Verification gate"]
  Verify --> Review["Reviewable diff"]
  Review --> Memory["Memory and history"]
  Memory --> Plan

Preview a task:

phonton plan --json "add input validation to config loading"

For broad goals, v0.19.0 adds typed swarm planning evidence. The plan preview records whether swarm metadata is enabled, why it was enabled or disabled, how subtasks are assigned, and which conflict groups should serialize overlapping file scopes.

swarm_mode
swarm_reason
assignments[].role
assignments[].expected_touch_scope
assignments[].verification_intent
conflict_groups[]

Before a real task​

Check the local environment and provider before asking Phonton to edit a repo:

phonton doctor
phonton doctor --provider

Then preview the plan:

phonton plan "add input validation to config loading"

If the plan is too broad, narrow the goal before running the interactive loop. When a provider-backed planner is configured, broad goals can produce richer swarm metadata. Without a configured provider, the deterministic planner records a visible fallback reason.

Execution and verification​

Workers remain diff-oriented. The orchestrator can dispatch independent DAG nodes concurrently, but v0.19.0 inserts dependencies for subtasks that share an expected touch scope so they do not race over the same files.

Review the latest completed task:

phonton review latest
phonton review approve latest
phonton review reject latest
phonton review rollback latest 1

Memory​

Persistent memory should capture decisions that matter across tasks:

phonton memory list
phonton memory pin <memory-id>

Review and history surfaces should make memory influence visible enough for a developer to understand why a plan or verification decision changed.

Good first task​

Choose a task that is small enough to verify:

  • Add validation to an existing config path.
  • Refactor one renderer into smaller helpers.
  • Add integration tests for one command.
  • Improve diagnostics for one error case.

Avoid broad first tasks like "rewrite the app" or "modernize everything." Phonton is most useful when the goal can be planned, changed, checked, and reviewed.