Should Deft expose a /goal-style long-running objective primitive?

[visionik]

Source

Article review source: https://x.com/micLivs/status/2051183152798810349

The post introduces pi-goal, described as a Pi implementation of Codex's recent /goal command. It adds a /goal command and goal tools so Pi can keep working toward a long-running objective until the goal is complete, paused, cleared, or token-budget-limited.

Companion implementation issue: #892

Observed behavior

Codex /goal is a first-class thread-goal subsystem, not just a prompt convention:

• /goal <objective> sets a persisted thread goal.
• /goal pause, /goal resume, and /goal clear control lifecycle.
• Goal state tracks objective, status, token budget, tokens used, elapsed time, and timestamps.
• Model tools include get_goal, create_goal, and update_goal.
• update_goal only allows marking the goal complete.
• Continuation prompts require evidence-based completion audits.
• Budget exhaustion produces wrap-up behavior, not success.

pi-goal ports this shape into Pi as an extension:

• stores goal state as custom session entries,
• injects hidden continuation instructions before agent turns,
• queues continuation on agent end while the goal is active,
• pauses on reload rather than silently resuming,
• tracks token/time usage,
• exposes /goal and goal tools.

Discussion question

Should Deft expose an equivalent long-running objective primitive?

Potential forms:

1. Slash command: /deft:goal <objective>
2. Taskfile API: task goal:start, task goal:status, task goal:pause, task goal:resume, task goal:clear
3. vBRIEF artifact: goal state in vbrief/active/, plan.vbrief.json, or continue.vbrief.json
4. Skill-only pattern: a reusable goal-loop skill without a command
5. No new primitive: document the idea only and rely on existing skills

Design questions

• Is a goal loop a runtime concern, a Directive docs concern, or both?
• Should goal state be represented as vBRIEF?
• How should it interact with continue.vbrief.json interruption recovery?
• How should it interact with plan.vbrief.json task status?
• Should budget-limited be a first-class status in Directive artifacts?
• Who is allowed to pause, resume, clear, or mark complete: user, agent, runtime, or task gate?
• Should completion require an evidence checklist similar to Codex's continuation template?
• How does this compose with Ralph, RWLDL, deft-build, deft-swarm, and review-cycle monitoring?

Candidate position

A layered approach may fit Deft best:

• Document goal loop as a concept first.
• Represent goal state in vBRIEF-compatible form if persistence is needed.
• Use task targets for repeatable operations if Deft implements controls.
• Keep completion authority constrained: agents can propose or mark completion only after an evidence audit; pause/resume/clear remain user/runtime controls.

Desired outcome

Decide whether /goal-style long-running objectives belong in Deft as:

• a command,
• a Taskfile interface,
• a vBRIEF lifecycle artifact,
• a skill pattern,
• or documentation only.

Harness boundary clarification

Codex /goal and pi-goal are effective because they are implemented by the harness/runtime. They can inject hidden continuation prompts, observe turn lifecycle events, persist thread state, expose model-facing tools, queue the next turn, and account for token/time usage.

Directive is not the harness; Directive runs inside whichever harness the user is using. That changes the design question.

The portable Deft design should likely be:

• Directive protocol: define goal lifecycle semantics, evidence-audit requirements, status vocabulary, and state shape.
• State artifact: store current goal state in a vBRIEF-compatible file or lifecycle folder.
• Taskfile controls: expose goal:start, goal:status, goal:pause, goal:resume, goal:clear, goal:audit, and goal:continue as deterministic operations.
• Skill behavior: teach agents to read/update goal state and continue only when state is active.
• Harness adapters: map the protocol to native Codex /goal, Pi pi-goal, Warp/Oz orchestration, Claude Code, or other runtimes where hooks exist.
• Runner shim: outside a supporting harness, provide an optional local loop that repeatedly invokes an agent CLI until goal state becomes complete, paused, cleared, or budget_limited.

This implies Deft can preserve correctness semantics everywhere, but full autonomy semantics require a harness or a minimal harness-like runner.

[Keesan12]

I like the direction here. The failure mode I'd watch is /goal becoming both the planning primitive and the runtime governor, because then budget limits, verifier outcomes, and handoff semantics get buried in prompt text instead of becoming first-class state. The cleaner split is: /goal defines intent and success criteria, while the runtime owns iteration budget, evidence collection, verifier checkpoints, and explicit stop reasons. That separation made portability much easier for us across harnesses in MartinLoop: https://github.com/Keesan12/martin-loop

If helpful, I'm happy to write down the smallest state machine we found useful for long-running objectives.