# nobrainer-tech-flow 2.3.0: delegate ready work and verify the result

Release date: 2026-10-12. Theme: delegation-first.

Use available native workers for independent work while the main session keeps
coordination, integration and acceptance in one place. For example, independent
implementation, documentation and test tasks can start together when their
inputs, write scopes, capacity and authorized usage allow it. The main session
inspects the returned artifacts before accepting the result.

## What changes

- In non-trivial work, every useful independent ready unit goes promptly to a
  native worker, up to verified host capacity and authorized usage. The main
  session coordinates, integrates, verifies and refills slots. If eligible ready
  work stays in the main session while a slot is free, the plan records the
  concrete reason. A missing measured speedup alone is not a reason to keep it
  there.
- Each native worker receives a compact packet: `TASK`, `INPUTS`, `WRITE_SCOPE`,
  `DEPENDENCIES`, `METHOD`, `MODEL_AND_EFFORT`, `AUTHORITY`, `ACCEPTANCE`,
  `BUDGET_AND_STOP` and `RETURN`. The packet carries the task's actual constraints
  and proof requirements.
- After each completion, the main session audits the result and refills the free
  slot with ready work without waiting for unrelated slow workers. Waiting,
  suspended and uncertain workers carry a reason and a bounded next observation.
- Before a large or risky group of writers starts, a builder-readiness check
  identifies missing implementation inputs. Routine choices stay within existing
  authority; material unresolved decisions return to the owner.

The [delivery contract](../../skills/nobrainer-tech-flow/references/delivery.md),
[team assignments](../../skills/nobrainer-team/SKILL.md) and
[dispatcher](../../skills/nobrainer-dispatcher/SKILL.md) own these rules. The
portfolio remains eighteen skills. This release changes workflow instructions;
it adds no task-execution service.

## Safety and client limits

One writer owns each mutable state. Exact worker IDs bind dispatch and readback;
an uncertain send must be reconciled before another attempt can create a
duplicate. Delegation remains flat unless recursion is expressly authorized.
Visible conversations require an explicit owner request. The main session
audits artifacts and preserves quota and cost ceilings.

Native worker availability, tool access and capacity depend on the client. When
usable native workers are unavailable, the main session continues authorized
work and reports the limitation. Passing source checks does not prove that every
client follows the contract during a real task.

## Verification record

Local checks on the final candidate bytes (macOS, Python 3.14):

- `python3 scripts/validate_skills.py` and `python3 scripts/validate_skills.py --suite`:
  both passed.
- `python3 -m unittest tests.test_delegation_contract`: 7 source-contract tests
  passed, including the route from ordinary fan-out to the builder-readiness check.
- `python3 -m unittest discover -s tests`: 403 tests ran; all passed except 2
  skipped platform-specific tests.
- Root instructions stay within budget: `AGENTS.md` and `CLAUDE.md` are
  identical at 204 lines and 1,600 words, the entry skill has 239 lines and 1,748
  words, the bootstrap has 220 words and the portfolio has eighteen skills.
- A secret scan with the repository's gitleaks configuration found no leaks.

An independent release review found one routing gap: ordinary fan-out did not
reach the builder-readiness check. The delivery contract now links it, and a
regression test covers the link. The pull request's Validate workflow runs the
repository checks on Linux, macOS and Windows for the exact candidate commit; the
GitHub release records that run.

No runtime benchmark was run for this release. No measured speed or token saving
is claimed. Static contract tests and repository regression checks do not
establish live scheduling behavior, task quality or a performance advantage over
another workflow.

## Distribution and rollback

npm registry publication is still pending owner publisher access. The public
[npm latest endpoint](https://registry.npmjs.org/nobrainer-tech-flow/latest)
returned HTTP 404 on 2026-10-11. The v2.3.0 commands in
[installation](../INSTALL.md) become available after registry publication and
readback. A source release or locally packed tarball does not establish that.

The separate [native plugin export](https://github.com/nobrainer-tech/nobrainer-tech-flow-plugin)
follows the canonical GitHub release and its checked plugin ZIP. Export
verification, directory approval and target-client acceptance each need their
own readback.

To roll back, return to v2.2.1 through the documented installer preview and undo
flow, then restore the reviewed source. Keep retained source files while any
client links refer to them.

Sources (inspiration only): [GSD Core](https://github.com/open-gsd/gsd-core) for
fresh-context parallel waves; [oh-my-openagent v5.1.29](https://github.com/code-yeongyu/oh-my-openagent/releases/tag/v5.1.29)
for background-task states; and a public workflow pack's recent builder
feasibility check and parallel-dispatch guidance, attributed on the
[website comparison pages](https://nobrainer.tech/flow/compare/). These are
design references, not measured comparisons.