Flownix
Начать
Sections
On this page

Close a task in strict mode

What closing requires when documentation must change with the code, and why a delta is the whole document.

In strict mode a task cannot be closed until the change is reflected in the documentation. What the mode is and why it exists is in the explanation; this page is the procedure.

Turning it on

The project header has a policy panel; strict mode is the first switch. Before enabling it, the dialog names the consequence: tasks will stop closing without a spec update.

An agent can do it too, if your hands are full:

in the agent session
turn on strict spec mode

It calls set_project_policy and rewrites the mode in .flownix — with the value the server returned, not the one that was asked for. The two differ when the write was rejected, and the config is read as fact by every other skill.

Strict mode is the first of three spec policies, and the other two do not work without it. What each one gives you is in the explanation; the order of work the third one introduces is in the spec-first guide.

What closing requires

Exactly one of two things. There is no third option; that is the entire point.

Documented behaviour changed

The agent rereads the affected document, assembles its complete new body, proposes it as a delta and applies it.

shell
propose_doc_delta({ doc_slug, source_node_slug, body: "<the entire document>", reason })
apply_doc_delta({ revision_id })

The body is the whole document, not the changed part. Applying replaces the content wholesale: a fragment silently collapses the document to that fragment. Hence the order: reread the current document, keep everything still true, make the change, send the result.

Applying checks the document version. If the document changed after the delta was proposed, the apply fails — reread and propose again. That is how two parallel edits avoid overwriting each other.

Behaviour did not change

shell
declare_no_spec_impact({ slug, reason: "<a sentence naming what changed and why it is not documented behaviour>" })

The reason is a sentence, not a formality. "n/a", "none" and single words are rejected by the server. If you cannot write the sentence, the behaviour probably did change and a delta is what is needed.

How it looks in practice

  1. The agent does the work.
  2. Before closing it asks itself: did a contract or behaviour described by the documentation change?
  3. Yes — propose and apply a delta. No — declare no impact, with a reason.
  4. Only then is the done status accepted.

The server verifies this itself. It cannot be bypassed — and the check holds in all three places where a node can reach done, not just the obvious one.

Who needs it

A product with a contractual API, where promises to integrations must update in the same cycle as the implementation. A team of several agents, where the next one reads the spec instead of reconstructing intent from commits. Anywhere audit matters: every document change is tied to its source, version, reason and time.

A prototype or a personal project does not need it and will find it in the way. The mode switches off as easily as it switches on.

Next