Workflow status

TCAF separates how complete a documentation page is from how strongly the underlying workflow has been implemented and verified.

The two dimensions are independent. This prevents polished writing from being mistaken for operational proof and prevents a verified procedure from disappearing simply because its public explanation is still being expanded.

Content status

complete

The page has a complete bilingual explanation for its current editorial scope. It may still evolve with new examples, evidence or later TCAF versions.

complete does not mean that every workflow described by the page is verified in every tool, model or project configuration.

draft

The page contains useful material, but one or more editorial elements are still incomplete. Typical reasons include:

• examples still need review;
• a section is intentionally shorter than the final target;
• source links or evidence references are still being reconciled;
• the Italian and English texts are complete enough to publish but not yet considered final.

placeholder

The route exists in the published documentation structure, but the complete bilingual explanation has not yet been authored.

A placeholder is explicit. TCAF never silently displays English content on an Italian route or Italian content on an English route.

Workflow status

verified

The workflow or capability has been executed successfully in a representative test or real project path and its expected behavior has supporting evidence.

Verification is scoped. It does not imply that every combination of model, operating system, adapter and project type has been tested.

verified-with-limitations

The core workflow has been exercised successfully, but a known tool, transport or coverage limitation remains.

The Cline manual-envelope workflow is an example: the bounded procedure is verified, while native runner-to-Cline invocation remains unverified and UI approval behavior can require manual handling.

framework-aligned

The workflow is defined consistently with the approved TCAF architecture and operating principles, but it has not yet passed enough dedicated acceptance testing to be labelled verified.

The documentation may still be complete. The status tells the reader not to confuse design completeness with empirical validation.

documentation-in-progress

The workflow exists or has evidence, but its public documentation is being reconciled and should not yet be treated as the stable reference.

This state is available for transitional use when the operational source and the public explanation are temporarily out of sync.

planned

The capability is intentionally included in the roadmap but is not yet available or validated as an operational workflow.

A planned page may explain the intended boundary and current limitation so readers do not infer support that does not exist.

not-supported

TCAF deliberately does not perform the operation as an autonomous framework action.

For example, Git staging, commit, tagging and push remain separate developer-authorized operations. Documentation may explain their safe place in the process without presenting them as automatic agent permissions.

No workflow status

Informational pages, navigation pages and conceptual overviews may have no workflow status because they do not represent one executable procedure.

How to read a page header

A page can legitimately be:

• content: complete and workflow: framework-aligned;
• content: draft and workflow: verified;
• content: placeholder and workflow: planned;
• content: complete with no workflow status.

Always interpret both badges together.

Verification is evidence, not a universal guarantee

TCAF is currently pre-1.0. Existing verification demonstrates that specific paths behaved as expected under documented conditions. It does not guarantee identical behavior for every future model, host integration or repository.

That is why the framework uses:

• explicit adapter status;
• scoped evidence;
• developer review gates;
• outcome labels such as PASS, PARTIAL, BLOCKED and FAIL;
• visible limitations instead of optimistic inference.

When a status should change

A status should be updated only when the underlying evidence changes:

• successful acceptance testing may promote framework-aligned to verified;
• a newly discovered limitation may change verified to verified-with-limitations;
• implementation removal may require planned or not-supported;
• completion of both language versions may promote content from draft or placeholder to complete.

Status changes are documentation and project-state work. They should be reviewed rather than inferred automatically from a successful code edit.