CAF 0.3.0

Summary

CAF v0.3.0 is the release where the framework starts to feel much more operational end-to-end.
CAF now carries product and architecture intent more reliably through the full path from PRD to architecture to plan to candidate build.

Compared with v0.2.0, v0.3.0 is more concrete in four ways:

• PRD is much more clearly part of the default lifecycle, not an optional side path.
• Important architectural choices such as ORM, auth mode, and runtime wiring are more likely to survive all the way into planning and generated outputs.
• More repeated expectations now live in framework-owned contracts, terminals, enrichers, and gates instead of depending on worker-specific lore or prompt luck.
• The runnable demo and sample story are more believable: the generated stack is closer to something a developer can actually run, inspect, and learn from.

What changed since v0.2.0

1. PRD became part of the actual default CAF lifecycle

CAF now treats PRD as part of the normal path instead of a side workflow.

That shows up in a few practical ways:

• Seeded architecture shape is explicitly marked as a bootstrap default
• PRD promotion stamps the shape as lifecycle-ready
• Architecture gates fail closed when the authoritative shape is still only a template seed
• user-facing docs now present the PRD-first flow much more clearly

In practical terms, this means CAF is better at distinguishing “we have a starter scaffold” from “we have a shaped product definition that should drive downstream work.”

2. Architectural decisions are more likely to survive the derivation cascade

A major theme is decision consumption.

In v0.2.0, CAF was already getting better at expressing decisions. In v0.3.0, it became more serious about ensuring those decisions remain visible when they matter.

The framework tightened propagation and fail-closed checks for:

• resolved technology choices
• adopted design options
• interface-binding intent
• required inputs on concrete tasks
• obligation traces that show why a task exists and what it is supposed to honor

This is the practical meaning of the derivation-cascade work: choices made in spec and design are less likely to disappear before planning and build. The framework is more explicit about what is authoritative, what is derived, and where drift should fail, rather than being silently normalized away.

3. More responsibility moved into framework-owned terminals and contracts

Another strong theme since v0.2.0 is ownership cleanup.

CAF moved further away from relying on workers to “remember” stack semantics and further toward expressing them once in framework-owned terminals, contracts, enrichers, rubrics, and gates.

This shows up in several concrete areas:

• SQLAlchemy became a first-class persistence terminal instead of an implied worker behavior
• raw SQL also became a first-class supported terminal rather than an approved-but-under-owned option
• Python packaging expectations were normalized around a canonical dependency manifest surface
• mock auth expectations were tightened around explicit claim shape, boundary adapters, and owning files
• pattern obligations and deterministic post-plan attachments moved into compiler/enricher paths instead of staying planner-heavy

In plain English, CAF is doing a better job of putting reusable expectations in the framework itself rather than scattering them across prompts and task-local instructions.

4. SQLAlchemy and database/runtime wiring became much more real

Since v0.2.0, CAF has made a series of corrections that moved SQLAlchemy from “selected in theory” toward “realized in a way that actually matters at runtime.”

Highlights include:

• resolved technology choices now propagate the selected ORM into the main resolved profile surface
• TBP-SQLALCHEMY-01 was added so ORM realization pressure lives in a first-class framework terminal
• planning and build gates were strengthened so selected ORM and schema-management choices cannot disappear quietly
• DB URL ownership was corrected so URL expectations live with the right runtime/ORM seam rather than leaking into unrelated surfaces
• schema bootstrap and model-registration runtime issues were fixed
• the shared SQLAlchemy session-opening contract was corrected so generated repositories can open sessions in the styles CAF actually emits

The practical result is simple: if CAF says a service is using SQLAlchemy, that claim is now under much stronger pressure to be true in the generated code and runtime helpers.

5. The demo and UI story got more believable

v0.3.0 also made the generated product surface feel more like a real application and less like a static mock-up.

Important changes here include:

• a stronger SPA review rubric so descriptive-only pages do not pass as implemented UI
• tighter UI worker expectations around wiring, action paths, and visible page states
• fixes to same-origin local routing across UI, AP, and CP so local runs behave more like a coherent stack
• better handling of identifier visibility and flow handoff on resource pages
• clearer scoping for policy-admin surfaces so they match the declared backend contract instead of overclaiming CRUD
• a reusable demo-enablement posture that makes the happy path easier to show without smuggling sample-specific exceptions into the workers

This is also where the demo work became more intentional. CAF kept the plain SaaS starter while adding an opt-in governed agentic review starter, which makes the modernization story much easier to demonstrate without turning the default starter into an AI-first template.

6. Auth became clearer, more explicit, and easier to diagnose

Authentication and tenant-context handling were another major source of concrete improvement.

The patch history shows several rounds of cleanup here:

• explicit mock claim shape and clearer Authorization/Bearer expectations
• cleaner ownership boundaries for auth helpers, boundary adapters, and UI/API emission
• better runtime regression coverage and smoke checks
• better 401 diagnosis guidance in companion surfaces
• cleanup of stale auth scaffold idioms that no longer matched the canonical flow

The developer-facing result is that local auth behavior is less mysterious, the expected claim shape is clearer, and the framework is less likely to mix claim semantics with header-shaped shortcuts.

7. CAF became better at preserving framework intent without bloating the planner

A quieter but important theme in v0.3.0 is that CAF became more disciplined about where complexity lives.

The planner still owns task structure, IDs, dependencies, and rationale. But more framework-authored pressure now attaches deterministically after planning, rather than forcing the planner to restate everything perfectly every time.

That includes work such as:

• semantic acceptance attachment
• required input enrichment
• UI seed pressure preservation
• compiler-owned pattern obligations
• obligation-trace attachment

This matters because it makes the framework more stable on weaker runners and reduces the number of places where important expectations can get lost or distorted.

8. Public docs and the user journey are more coherent

The main journey is clearer:

• ask-first remains a visible entry point
• Creating your own instance remains a clear second path
• the PRD-first lifecycle is easier to understand
• The docs do a better job of routing by role and by goal
• The release/demo story is less fragmented than it was in the v0.2.0 era

What did not change

CAF still produces candidate artifacts.

Human review still matters.

The framework still prefers fail-closed behavior when required inputs or ownership boundaries are unclear.

v0.3.0 does not claim to have solved every runtime-proof or packaging issue. The important change is that the framework is now much better at exposing those seams in the right place and carrying the right expectations forward.