Skip to content

CAF 0.4.0

Latest
Latest

Choose a tag to compare

View all tags
@arylwen arylwen released this 11 Apr 13:38
v0.4.1
d38b6ca

CAF 0.4.1 release notes

CAF 0.4.1 is a lifecycle-hardening and public-surface alignment release.

This release tightens the default PRD-first lifecycle, makes the architecture handoff and planner/build ownership boundaries more explicit, improves the optional richer UX lane to the public command list, and hardens routed execution and local Claude-compatible runner recovery.

Release focus

0.4.1 is about making CAF easier to run and easier to trust:

  • the default lifecycle is now clearly PRD-first instead of treating seeded architecture shape as already lifecycle-ready;
  • the second /caf arch pass is now documented as the design elaboration pass that planning depends on;
  • the backlog markdown is as a projected human view of the semantic task graph rather than the planner’s canonical source of truth;
  • the optional richer UX lane is part of the command surface ;
  • routed execution, session ownership, resume behavior, and claude-local / LM Studio recovery are more explicit and more deterministic.

What changed

1. PRD-first lifecycle is now the default path

CAF now treats /caf prd as a first-class lifecycle step between /caf saas and the first /caf arch.

The documented default sequence is:

/caf saas <instance>
/caf prd <instance>
/caf arch <instance>
/caf next <instance> apply
/caf arch <instance>
/caf plan <instance>
/caf build <instance>

# optional richer UX lane
/caf ux <instance>
/caf ux plan <instance>
/caf ux build <instance>
  • /caf saas seeds editable source artifacts and a bootstrap architecture shape;
  • /caf prd resolves PRD source docs into a lifecycle-ready authoritative shape;
  • the first /caf arch scaffolds the system architecture from that authoritative shape;
  • /caf next <instance> apply checkpoints the adopted system architecture;
  • the second /caf arch elaborates the design bundle that planning consumes.

2. Lifecycle provenance and source-vs-derived separation are more explicit

The 0.4.1 docs now make the lifecycle provenance of the authoritative shape explicit:

  • seeded_template_default
  • prd_promoted
  • architect_curated

The release also strengthens the distinction between:

  • human-owned source artifacts such as PRDs and editable architecture-shape inputs;
  • derived artifacts such as resolved PRD views, architecture scaffolds, planning outputs, and candidate build outputs.

This matters because CAF is supposed to keep human-edited inputs legible and auditable rather than silently overwriting them with generated derivative state.

3. Second-pass architecture elaboration is more explicit, including AP/CP-aware design outputs

The second /caf arch pass is now described more concretely as the system/design elaboration phase that planning depends on.

Typical outputs include:

  • design/playbook/control_plane_design_v1.md
  • design/playbook/application_design_v1.md
  • design/playbook/contract_declarations_v1.yaml
  • normalized domain-model YAML views
  • design/playbook/design_summary_v1.md
  • CAF-managed planning payload blocks

This is important because 0.4.1 is not only about producing a first architecture scaffold. It is also about making later design choices legible, including AP/CP separation, interface posture, contract declarations, normalized domain views, and the design material that later planning and UX work rely on.

4. Planner vs backlog projection ownership is clearer

CAF planning is centered on the semantic planning bundle and task graph.

In 0.4.1, the public docs consistently describe:

  • /caf plan <instance> as the owner of the semantic planning outputs;
  • /caf backlog <instance> as the projection step for the human-facing markdown backlog.

That split matters because the backlog markdown is useful for review and work visibility, but it is not the semantic source of truth that planners, enrichers, and gates should mutate independently.

5. The optional richer UX lane is now part of the public surface

CAF 0.4.1 makes the richer UX lane explicit in the public docs and command surface:

  • /caf ux <instance>
  • /caf ux plan <instance>
  • /caf ux build <instance>

This lane is additive:

  • it runs after the second /caf arch and the main /caf build lifecycle is established;
  • it derives explicit UX artifacts and UX planning outputs;
  • it realizes a richer UX layer against the already-built backend/runtime truth instead of inventing a separate backend contract.

6. Routed execution and resume behavior are harder to misuse

0.4.1 continues the routed-step-state hardening work.

CAF now ships a shared routed-step-state model and helper surface so reruns can reason from explicit step status and checkpoint evidence instead of relying only on artifact presence.

The shipped flow helpers also preserve per-step runner-session ownership for Claude-compatible runs and only resume/continue when the stored session still matches the exact step and /caf ... command being executed.

7. claude-local / LM Studio support is more operationally usable

The claude-local helper is now documented and centralized more explicitly.

This includes:

  • a central claude-local configuration map;
  • documented CAF_CLAUDE_LOCAL_* runner and recovery variables;
  • LM Studio load / recovery knobs such as CAF_CLAUDE_LOCAL_LMSTUDIO_LOAD_MODE;
  • explicit local-endpoint environment injection while preserving the same routed CAF lifecycle semantics as the main Claude helper.

8. Recovery and false-blocker handling are tighter

The routed full-flow helper resolves matched packets after a successful rerun before treating remaining fresh pending packets as terminal blockers.

That matters for local or unstable runners because a step can genuinely complete while older matched packets are still visible. The 0.4.1 behavior is tighter about distinguishing:

  • real blocking packets produced by the current failing run,
  • stale packets that predated the run,
  • and packets that should be auto-resolved once the step is now provably complete.

Public command surface in 0.4.1

The public /caf surface is now consistently documented as:

  • /caf help
  • /caf ask
  • /caf saas
  • /caf prd
  • /caf arch
  • /caf next <instance> apply
  • /caf plan
  • /caf backlog
  • /caf build
  • /caf ux
  • /caf ux plan
  • /caf ux build

Operational notes

  • CAF remains candidate-only: generated code and generated documents still require human review.
  • CAF remains fail-closed: when a lifecycle step cannot prove its downstream contract, CAF should emit a feedback packet instead of guessing.
  • Release bundles may keep canonical sample instances such as codex-saas separate from the core framework bundle; public docs should still use one consistent sample name.
  • Local-model ergonomics, especially around more fragile local runners, remain an operational area to keep improving after 0.4.1 even though the framework-side lifecycle and recovery posture are stronger.

Upgrade notes for existing users

If you already use CAF:

  • prefer the PRD-first default lifecycle when starting fresh work;
  • treat the second /caf arch as the design elaboration pass that planning depends on;
  • treat /caf backlog as a projection step, not the semantic planner source of truth;
  • use the documented claude-local helper and central CAF_CLAUDE_LOCAL_* configuration map for local Claude-compatible endpoints.
Assets 2
Loading