nobrainer-tech-flow 0.0.0-stage → 2.4.0

package/docs/MIGRATION_TO_FLOW.md

@@ -0,0 +1,117 @@
+# Move to nobrainer-tech-flow
+
+Version **1.7.1** introduced an earlier display spelling.
+The current display name is **nobrainer-tech-flow**; the repository,
+public package/plugin identity and entry skill are `nobrainer-tech-flow`.
+**From task to done.** Tell it what you need. nobrainer-tech-flow clarifies the goal,
+does the work, and checks the result.
+
+The canonical public repository identity is
+[`nobrainer-tech/nobrainer-tech-flow`](https://github.com/nobrainer-tech/nobrainer-tech-flow)
+and the product website is [nobrainer.tech/flow](https://nobrainer.tech/flow/).
+The earlier 1.7.1 rename changed display/source routing. The 2.0.0
+upgrade also changes the entry skill and public package/plugin identities.
+Done still means the agreed criteria are met and the result is checked; missing
+access or an unresolved decision can require an explicit unblock action.
+
+## Existing installation identities
+
+The table below records the previous package identity for migration. Existing
+registrations must be updated deliberately; a second package next to the old
+one can cause duplicate routing.
+
+| Surface | Previous identifier and migration |
+|---|---|
+| Existing package and Claude Code, Codex, Cursor, Kimi, Gemini and portable plugin IDs | `nobrainer-tech-skills` -> `nobrainer-tech-flow` after exact client readback |
+| New public repository/package channel | `nobrainer-tech-flow` |
+| Claude Code marketplace name | `nobrainer-tech` |
+| Codex marketplace name | `nobrainer-tech-skills-dev` -> `nobrainer-tech` in 2.4.0 |
+| OpenCode package entry prefix | `nobrainer-tech-skills@git+` -> `nobrainer-tech-flow@git+` at a reviewed immutable ref |
+| OpenCode adapter module | `.opencode/plugins/nobrainer-tech-skills.js` |
+| Pi extension module | `.pi/extensions/nobrainer-tech-skills.js` |
+| Shared bootstrap marker | `NOBRAINER_BOOTSTRAP_V1` |
+| Technical entrypoint and compatibility aliases | `$nobrainer-ultra` -> `$nobrainer-tech-flow`; old triggers are recognized only for migration |
+
+If you added the Codex marketplace under its old name, remove it and add the
+repository again; otherwise the old and new plugin stay enabled side by side:
+
+```sh
+codex plugin remove nobrainer-tech-flow@nobrainer-tech-skills-dev
+codex plugin marketplace remove nobrainer-tech-skills-dev
+codex plugin marketplace add nobrainer-tech/nobrainer-tech-flow   # or your reviewed checkout path
+codex plugin add nobrainer-tech-flow@nobrainer-tech
+```
+
+The previous skill directory list is historical. The reviewed migration renames
+the entry skill and adds the calibration skill; do not overwrite a foreign
+installed target to force the migration.
+
+```text
+nobrainer-ultra
+nobrainer-team
+nobrainer-dispatcher
+nobrainer-research
+nobrainer-writing
+nobrainer-build
+nobrainer-security
+nobrainer-sessions
+nobrainer-spec-driven-development
+nobrainer-wiki
+nobrainer-browser
+nobrainer-autoimprove
+nobrainer-decide
+nobrainer-rca
+nobrainer-review
+```
+
+These are frozen predecessor identities. Do not rewrite their old release
+records. Current public installation has eighteen skills, including
+`nobrainer-tech-flow` and `nobrainer-auto-fine-tune`.
+
+## Update the source in place
+
+Use the client's supported upgrade mechanism. In OpenCode, change the old
+package prefix to `nobrainer-tech-flow@git+` and use an immutable reviewed
+commit pin. In plugin hosts, inspect the installed old ID and the new
+registration before retiring anything; a new ID can coexist with the old
+one and cause duplicate routing. Do not delete an unverified foreign target.
+
+Existing local checkouts can keep their directory names. Installed symlinks may
+point into that directory, so moving it is unnecessary. After confirming that
+`origin` is this project's remote, its URL can be updated in place:
+
+```bash
+git remote set-url origin https://github.com/nobrainer-tech/nobrainer-tech-flow.git
+```
+
+The [current installation examples](INSTALL.md) require an exact reviewed
+commit, validation and installer dry-run. `install_skills.py --migrate-legacy`
+handles only a verified old symlink owned by the same checkout; a copied or
+foreign old installation needs separate exact readback and a scoped migration.
+The old path is never deleted merely because the new skill was installed.
+
+The Reddit integration was retired from Flow. `install_skills.py`, its Python/npm
+callers and `install.sh` preserve foreign `nobrainer-reddit` files, directories
+and symlinks without blocking installation. The skill helper and shell installer
+print `PRESERVED_FOREIGN`. Exact old links owned by this checkout still block
+until migrated with `install_skills.py --migrate-legacy`. Foreign renamed aliases
+such as `nb-flow` and unresolved legacy names still block installation to prevent
+trigger conflicts.
+
+After an update, read back the source commit and package identity, restart the
+client and confirm that `nobrainer-tech-flow` loads once. A version change or an
+installed file alone does not establish runtime compatibility.
+
+## Old links and evidence
+
+The previous repository name is `nobrainer-tech/nobrainer-tech-skills` and the
+previous website route is `/skills/`. Their redirects, including corresponding
+deep links under `/flow/`, are separate publication checks. Do not remove an old
+installation or rewrite historical evidence to compensate for a missing redirect.
+
+Tagged releases, dated reviews, frozen evaluation payloads and their source hashes
+retain the original names and links as provenance. This rename adds no model
+performance, token-savings or cross-client runtime claim. See the
+[1.7.1 release record](releases/v1.7.1.md) for the local verification boundary;
+repository rename, website redirects and client update readback must be verified
+in their own systems.

package/docs/NAMING.md

@@ -0,0 +1,39 @@
+# nobrainer-tech-flow naming
+
+This map separates the public product language from compatibility and source
+identifiers. It is the canonical naming reference for maintained copy.
+
+| Class | Use | Rule |
+| --- | --- | --- |
+| Product | nobrainer-tech-flow | Use this exact name in user-facing prose, status, headings and display copy. |
+| Public repository/package channel | `nobrainer-tech-flow` | Use in repository links, new checkout paths and public source URLs. |
+| Workflow skills | `nobrainer-build`, `nobrainer-research`, `nobrainer-review`, etc. | Name the specific skill when it explains which part of the workflow is doing the work. Preserve its exact lowercase kebab-case name and inline-code formatting. |
+| Assistant conversation label | nobrainer-tech-flow | Do not open with a ritual entry announcement; mention the product or a specific skill only when it helps explain an action, constraint or result. |
+| X hashtag | `#NoBrainerTechFlow` | Use this punctuation-free form when a real hashtag is useful. A hyphen ends an X hashtag, so never publish `#nobrainer-tech-flow` as the tag. |
+| Legacy display name | Former display spellings | Preserve only in historical release evidence and compatibility metadata. Do not use it as the current product name in new prose. |
+| Technical entry skill | `nobrainer-tech-flow` | Use for the skill directory, frontmatter name, installer target and the Codex entrypoint: `$nobrainer-tech-flow:nobrainer-tech-flow` where Codex lists the module under the plugin name, `$nobrainer-tech-flow` where it lists it plainly. |
+| Retired entry name | `nobrainer-ultra` | Recognize only in migration notes for existing installations. Never direct a new user to invoke it. |
+| Active phrases | `NBFlow`, `NBF`, `nobrainer-tech-flow` | Use in natural-language requests. Exact skill loading is the name the client lists for the module (in Codex `$nobrainer-tech-flow:nobrainer-tech-flow` or `$nobrainer-tech-flow`) when the client supports it; do not create alias directories. |
+| Retired aliases | `nb-ultra`, `nb-flow`, `nb-workflow` | Preserve only in migration records for older installations. |
+| Public package/plugin identity | `nobrainer-tech-flow` | Use in new package manifests, plugin IDs and installation examples. |
+| Legacy package identity | `nobrainer-tech-skills` | Preserve only in migration guidance and old adapter module paths; update existing client registrations explicitly. |
+| Historical evidence | Prior product/package forms | Keep in dated releases, evaluations, hashes and frozen fixtures when changing them would rewrite provenance. |
+
+## Propagation plan
+
+The canonical source is updated first. Existing repository copies are then
+handled through the reviewed synchronization workflow after the source change
+is approved:
+
+1. inventory current consumer instruction files before propagation;
+2. classify each occurrence as maintained public text, technical identifier or
+   historical evidence;
+3. update only maintained public text and preserve managed blocks, local rules,
+   paths, aliases and technical identifiers;
+4. preview exact diffs and require per-repository dirty-state readback;
+5. apply through canonical synchronization, then run each repository's nearest
+   validator and record any owner-gated or conflicting checkout.
+
+This PR changes the canonical source. Install and personalize clients only
+after the owner reviews it; keep live client directories and caches untouched
+until the exact reviewed release is available.

package/docs/PRIVACY.md

@@ -0,0 +1,9 @@
+# Privacy for the nobrainer-tech-flow plugin
+
+nobrainer-tech-flow distributes MIT-licensed skills, reference documents and local helpers. The package has no publisher-operated backend, telemetry or account requirement. Installing this plugin does not transmit your conversation, files or credentials to NoBrainer Tech.
+
+Your AI client processes your task and may use its own tools under its permissions and privacy settings. Requested research can contact external sources. The optional release checker reads public GitHub release metadata; GitHub receives the ordinary network request. Optional Jev and Laya decision profiles remain off until you enable them with the required data and cost authority.
+
+The npm installer writes local release files and managed client configuration only with an explicit --apply flag. Review the preview before applying. Its undo preserves unrelated files. Release files retained for stable installation are documented in INSTALL.md.
+
+For questions or source issues, use https://github.com/nobrainer-tech/nobrainer-tech-flow/issues. Do not include private task data or credentials in public issues. The selected AI client's own terms and privacy policy govern that client's processing.

package/docs/SESSION_RESTART.md

@@ -0,0 +1,70 @@
+# Adaptive session restart
+
+Automatic Flow startup care has shipped since v1.10.0 on top of the v1.8.1
+restart protocol.
+
+Invoke nobrainer-tech-flow with resumable, long or delegated work. Flow runs startup
+naming and health assessment without a separate restart command; the quick path
+skips it. Flow entry enables observation only: restarting MAIN or archiving needs
+separately recorded owner consent. It preserves an existing `off` policy and obeys
+stricter host consent rules. Installation or incidental skill loading alone authorizes no mutation.
+Explicit automatic-restart consent remains valid for later rotations in scope;
+archival needs its own recorded authorization. Ordinary delegation uses native
+subagents; creating a separate visible conversation requires an explicit owner
+request or an explicitly authorized MAIN restart.
+
+On entry, supported clients name the session `<task title> | started DD-MM` using
+its actual creation timestamp and owner/task timezone (recorded UTC fallback).
+Resume preserves that date; a successor receives its own creation date. Missing
+metadata is unavailable, never replaced with today's date. Supported mutations
+are read back. Session IDs, goal identity and checkpoint digest remain authoritative.
+
+Flow assesses available context measurements and the complete next startup,
+including required skills, metadata, tools, checkpoint and necessary re-reads.
+It records measured versus estimated inputs and keeps missing values unknown.
+The agent performs the check at entry, after compaction and accepted milestones;
+there is no new daemon or timer-only model call.
+
+Health and economic benefit are independent reasons to rotate. A current pressure
+signal or at least 70% observed context occupancy, together with a complete fresh
+startup at most 80% of current input, qualifies the health path. Those are policy
+heuristics, not measured optima. Remaining work, progress since the last restart,
+verified checkpoint and safe native ownership transfer are still required.
+Two compactions and optional daily age of 24 hours trigger assessment only.
+A small post-compaction context or equally large startup can make continuing wiser.
+
+Routine care stays quiet. Report one successful continuation or an actionable
+capability failure. After takeover, compare observed startup and missing-context
+rework with the estimate in the same task state.
+
+The core is the [Sessions protocol](../skills/nobrainer-sessions/references/session-restart.md),
+usable as instructions in any capable client. An optional deterministic helper
+can be invoked by hooks. There is no universal hook event or universal archive
+API: adapters must verify capabilities and map their actual lifecycle events.
+A client without safe native transport prepares a manual continuation packet.
+
+For the independent economic path, the helper calculates a conservative raw token proxy over at most three future
+calls. Its defaults are heuristics, not an optimum or a billing forecast. Current
+input, fresh startup and restart overhead can be observations or explicitly
+labelled estimates. Missing metrics remain unknown. Large fixed instructions,
+cache reuse and necessary re-reads may make restarting more expensive.
+
+Quality is protected by checking the handoff before transfer, not by assuming
+fresh sessions are smarter. Do not restart if acceptance, decisions or required
+evidence cannot be reconstructed reliably. Do not archive the old session after
+mere creation or a read-only ACK. Verify takeover first; archive failure never
+returns implementation ownership to the old session.
+
+## Proof and remaining limits
+
+The shipped helper is tested with real CLI invocations and deterministic failure
+cases. It only chooses actions from supplied observations. It does not collect
+usage, authenticate an ACK, implement a lock, run a model, create sessions or
+archive them. Native transport requires separate adapter runtime evidence.
+No all-client automation, token-saving percentage or quality improvement has
+been measured for this feature.
+
+No new permanent module, scheduler, background service or global hook is added.
+Existing `nobrainer-sessions`, `session-handoff` and manual recovery stay available.
+Disable further rotation with policy `off`; a committed transfer never permits
+both old and new sessions to resume writing.

package/docs/SKILL_CURATION.md

@@ -0,0 +1,124 @@
+# Skill curation
+
+The active product is deliberately small enough to understand and broad enough
+to run a non-trivial project from intent to verified outcome. A skill belongs in
+the permanent suite only when it owns a recurring cross-project boundary that
+cannot live clearly inside another owner.
+
+## Admission test
+
+A permanent skill must pass every condition:
+
+1. It has a distinct trigger and observable result.
+2. It is useful across projects without private paths or accounts; any client-specific capability has an explicit compatibility boundary.
+3. Loading it only when triggered saves more context and risk than embedding its
+   full protocol in Flow.
+4. Its behavior is not already owned by another active skill or a maintained
+   project/native capability.
+5. Its failure, stop, owner-gate and rollback behavior can be tested.
+6. It has a pressure scenario showing value and a non-trigger case preventing
+   overuse.
+
+Popularity, file size and prior existence are not admission criteria.
+
+## Active eighteen
+
+| Skill | Distinct owner |
+|---|---|
+| `nobrainer-tech-flow` | One request through brief requirements, concise progress, guarded execution, audit, recovery and learning. |
+| `nobrainer-team` | Capability selection and bounded native assignments, installed capability inventory and safe temporary specialist discovery. |
+| `nobrainer-dispatcher` | Ready-set calculation, dependency-aware bounded batches, backpressure and audited result routing. |
+| `nobrainer-research` | Bounded current external research and source-quality/freshness control. |
+| `nobrainer-writing` | High-signal drafting, compression, voice and prose integrity across human-facing text artifacts. |
+| `nobrainer-build` | Implementation, engineering principles, anti-slop, test blast radius and simplification. |
+| `nobrainer-security` | Threat model, security review, supply-chain inspection and security release evidence. |
+| `nobrainer-sessions` | Exact visible session identity, transport, writer ownership, handoff, receive-audit and recovery. |
+| `nobrainer-spec-driven-development` | Durable behavior contract and acceptance ledger when risk/dependencies justify it. |
+| `nobrainer-wiki` | Setup, targeted retrieval, sourced capture and deterministic maintenance of durable knowledge. |
+| `nobrainer-browser` | Rendered UI, bounded CDP profile restart, approved browser-session attach, browser tests and trace evidence. |
+| `nobrainer-autoimprove` | Measured artifact improvement with baseline, holdout, budget and keep-or-revert. |
+| `nobrainer-auto-fine-tune` | Calibrates native worker routes against verified host capability, quality, latency and cost evidence while MAIN retains the owner's model. |
+| `nobrainer-decide` | One consequential decision after alternatives, scoring and adversarial attack. |
+| `nobrainer-rca` | Read-only causal diagnosis of an observed failure. |
+| `nobrainer-review` | Final acceptance/bug/release evidence gate and verified actionable findings. |
+| `nobrainer-codex-context` | Project-local Codex instruction discovery, byte-budget audit, safe context-block setup and runtime readback. |
+| `nobrainer-skill-doctor` | Cross-project audit of skills, project instructions and task prompts, with coverage, overlap and minimal portfolio repair planning. |
+
+## Boundaries that stay embedded
+
+Do not create separate permanent skills for:
+
+- planning, autopilot, general NoBrainer setup or correction capture: the Flow entry skill owns the lifecycle; Codex-specific project-context setup belongs to `nobrainer-codex-context`;
+- visible goal/TODO progress: Flow owns one canonical plan and its compact view;
+  do not add a separate goal, todo or progress skill;
+- KISS, DRY, SOLID, YAGNI, simplification or test safety: Build owns them;
+- brand-specific voice facts belong in a project guide or wiki; Writing owns the
+  portable prose method and can consume an authentic supplied voice sample;
+- generic code review, bug finding or release ceremony: Review owns the close
+  gate, while Security owns only material trust-boundary risk;
+- human continuation snapshots: Sessions mode `handoff` owns them;
+- a local skill catalogue: Team builds a metadata-only capability index;
+- wiki add/get/tidy wrappers: Wiki exposes explicit modes;
+- personal model presets, accounts or repository-specific configuration: keep
+  them in project/private instructions. A named host integration must justify
+  its recurring boundary and state its compatibility limits.
+
+## Dynamic specialist policy
+
+Team resolves a capability gap in this order:
+
+1. curated NoBrainer skill;
+2. already installed and inspected specialist;
+3. maintained project/API/CLI/native capability;
+4. bounded current research;
+5. temporary external skill discovered for the exact missing capability.
+
+External instructions are untrusted. Search rank does not authorize install,
+scripts, credentials, network access or writes. Review immutable source/ref,
+license, permissions, trigger overlap, persistence and rollback. Persistent or
+global installation requires an owner gate and evidence that repeated use earns
+the added trigger/context surface.
+
+## Retirement test
+
+A skill can be removed only after:
+
+- its unique behavior is intentionally preserved or explicitly rejected;
+- inbound references and aliases are migrated;
+- the replacement is installed and discovered in a clean session;
+- representative old invocations route to the replacement;
+- rollback points to an exact reviewed ref;
+- no private operational contract is confused with a portable semantic
+  duplicate.
+
+Same name or broad topic is not proof of duplication. Until the above gates
+pass, classify candidates as `COVERED_NOT_RETIRED`, `PROJECT_SPECIFIC`,
+`UNIQUE_VALUE`, `OBSOLETE_WITH_EVIDENCE` or `UNKNOWN`.
+
+`nobrainer-fast-audit` is currently `UNKNOWN`, not a migration alias. Its exact
+contract and callers must be audited before choosing Review, Security or another
+owner. Keep an existing private installation unchanged until that audit and a
+clean-session parity check pass; the public installer must report it as a normal
+conflict rather than delete or silently remap it.
+
+`nobrainer-reddit` is `RETIRED`: the
+[portable-workflow curation](https://github.com/nobrainer-tech/nobrainer-tech-flow/commit/955de2a5cba72f86a9941a15c6ad9aa6b42c76d4)
+removed the Reddit CLI as a client/account integration; no active skill owns its
+functionality or trigger. `install_skills.py` and `install.sh` preserve foreign
+targets at that name with `PRESERVED_FOREIGN`. Only exact old links from this
+checkout remain migration candidates. Renamed/absorbed aliases retain blocking
+conflict checks.
+
+## Change control
+
+Any addition, merge or retirement updates together:
+
+- `skills/`, aliases and installer migrations;
+- validator and behavioral tests;
+- Flow routing and setup instructions;
+- README, compatibility and release notes;
+- clean-session trigger/readback evidence.
+
+Prefer strengthening an existing owner over creating a new noun. Do not keep an
+empty alias skill for compatibility; aliases belong in descriptions and
+migration maps.

package/docs/TESTING.md

@@ -0,0 +1,232 @@
+# Testing and evaluation
+
+The repository uses four evidence layers. A green lower layer never proves a
+higher one.
+
+## 1. Structure and public safety
+
+- portable frontmatter, directory/name identity and exact active inventory;
+- relative companion links and retired-name exclusion;
+- public-clean text, manifest parsing and version consistency;
+- installer conflict refusal, foreign retired-name preservation, exact legacy
+  migration, idempotence, readback, race-safe atomic restore and
+  preserved migration/rollback recovery claims;
+- secret scanning before publication.
+
+Run:
+
+```bash
+python3 scripts/validate_skills.py
+python3 scripts/validate_skills.py --suite
+```
+
+## 2. Deterministic behavior contracts
+
+Unit tests pressure the routing, model-policy and safety invariants that can be
+checked without an LLM: Flow states, bounded-turn `SESSION_HEALTH_GATE`,
+checkpoint/end-turn decisions, separate `RUNTIME_RELEASE`, session identity and
+lease gates, SDD boundaries, trigger ownership, browser routing, adapter
+registration and installer races.
+Adapter tests execute every bootstrap mechanism that can run locally: the Claude
+and Cursor SessionStart JSON shapes, OpenCode injection/deduplication (including
+a first message without a text part), and Pi discovery plus per-request
+injection. They also parse the portable Agent
+Plugin, Gemini and Kimi manifests, reject invented Devin/Hermes adapters and
+enforce the exact eighteen-skill inventory, correction hooks and workflow
+diagram contract.
+
+Static delegation contract checks cover ready-unit dispatch, the compact native
+packet, completion-driven refill and uncertain-send safeguards in the
+[canonical delegation contract](../skills/nobrainer-tech-flow/references/delivery.md#coordinated-team-execution).
+These source checks do not prove native worker launches, accepted runtime output,
+or any speed, token or quality gain. Those require a recorded client run.
+
+```bash
+python3 -m unittest discover -s tests -v
+```
+
+### Session-lifetime smoke
+
+[`tests/test_session_lifecycle.py`](../tests/test_session_lifecycle.py) is a
+deterministic, model-free protocol smoke. It covers the nominal clean-session
+trace, each health-gate event, configurable warning/hard limits, unknown and
+unsupported signals with safe bounded continuation, strict-budget refusal, checkpoint plus `END_TURN` without authorized rotation,
+`task_complete` with a live controlled worker followed by explicit release, and
+empty-ready-set handling: wait for running work, audit reports, finish accepted
+work, or surface a real owner decision. It also
+proves that resume reads the durable Markdown goal instead of stale summary
+text, and that host clear requires capability, no active writer and positive
+readback; otherwise the contract ends the turn or requires manual action. It does
+not prove that Codex, Claude Code,
+OpenCode or another host exposes those signals; that requires the clean-session
+readback below.
+
+GitHub Actions runs these deterministic layers on Linux and macOS, and the whole
+suite once more on Python 3.13 (a symlink-loop check that relied on an exception
+Python 3.13 no longer raises went unnoticed on 3.11). It checks
+Python, Node and shell syntax plus deterministic adapter contracts, and runs a
+checksum-pinned Gitleaks tree scan on Linux. A Windows job runs the structure
+validators, the adapter tests (including the LF pins for the hook scripts and the
+bootstrap), [`tests/test_windows_smoke.py`](../tests/test_windows_smoke.py):
+the hook wrapper under Git Bash, a copy-mode install, personalization and the UTC
+session title, and both one-command installers,
+[`tests/test_one_command_installer.py`](../tests/test_one_command_installer.py)
+and [`tests/test_shell_installer.py`](../tests/test_shell_installer.py) (the shell
+one under Git Bash), previewing, installing, repeating and undoing on that runner.
+CI sets `NOBRAINER_REQUIRE_SYMLINKS=1`, so a runner that cannot create links fails
+those tests instead of skipping them. It does not run the whole suite on Windows:
+some historical evidence tests compare text byte for byte and assume LF checkouts.
+CI does not claim a client UI or model followed a skill.
+
+The one-command installer tests run the real scripts against a private home:
+preview writes nothing, apply links every skill and writes one block without any
+standing authorization, a second apply changes nothing, undo puts the instruction
+file back byte for byte (and keeps edits made outside the block since), a foreign
+canonical target is refused before any write, and the variables and `--home`
+select the same place the helpers do. The shell installer's tests also run it in
+every POSIX shell found (dash, bash in POSIX mode, busybox sh, zsh emulating sh), with no Python on
+its `PATH`, and check that its block is byte for byte the Python helper's, that
+either installer undoes what the other did with the same bytes, and that a
+tampered setup record is refused. Both installers preserve foreign targets at
+retired names through preview, apply, repeat and undo, while exact old links,
+renamed aliases and unresolved legacy names still block. Shell tests compare
+exact-link classification with Python for absolute, relative, chained and looping
+links in every available shell. They also check that a second undo is a no-op
+that writes nothing, that undo removes the empty folders the setup created and no
+others, that a repeat apply says `UP TO DATE` without a restart hint, and that
+`install.sh` replaces a block of an earlier version while every byte around it
+stays. In the 2.0.2 measurement they caught 30 of 34
+mutants of `install.sh`; the [2.0.2 record](releases/v2.0.2.md) says why the
+other four were not caught.
+
+## 3. Forward behavior evaluation
+
+Historical v1.6 runtime receipts bind the frozen source archive, not a changing
+checkout. The test rejects missing, duplicate or altered archived entries and
+continues checking the original case and output hashes. A later instruction
+review is source-contract evidence unless fresh model runs are recorded for its
+exact bytes; it cannot upgrade the release's runtime proof.
+
+Behavior-shaping changes need a frozen scenario set, an unchanged baseline and
+an independent judge. Keep development cases separate from final holdout cases;
+do not tune against a failed holdout. Record accepted findings, null results,
+digest, rollback and any model/harness substitutions.
+
+Before baseline scoring, self-test the complete evaluator with known-good and
+known-bad controls plus a deceptive control when the metric can be gamed.
+Candidate writes must not reach the rubric, cases, score extractor or acceptance
+harness. Bind each score to target/evaluator/case identities and raw evidence;
+changed receipt fields require re-baselining. Predeclare equal repetitions for
+stochastic comparisons and require at least three paired runs for a borderline
+promotion claim.
+
+The [v1.6.1 evidence](releases/v1.6.1.md) records fresh response simulations
+and actual artifact execution, including failed behavioral gates. No measured
+model-quality promotion is accepted. Artifact integrity and score arithmetic
+are checked independently of those behavioral verdicts.
+
+The v1.6 probes and their source bindings are in
+[`releases/v1.6.0.md`](releases/v1.6.0.md). Source-only contract tests and
+one behavioral trial are not a comparative benchmark. Earlier changed-control records are
+[`evals/v1.3.0-harness-clarity-2026-08-30.md`](evals/v1.3.0-harness-clarity-2026-08-30.md),
+[`evals/dispatcher-routing-v1.2.0-2026-08-28.md`](evals/dispatcher-routing-v1.2.0-2026-08-28.md)
+and
+[`evals/writing-density-v1.2.0-2026-08-28.md`](evals/writing-density-v1.2.0-2026-08-28.md).
+The broader v1.1 routing baseline remains in
+[`evals/core-routing-v1.1.0-2026-08-28.md`](evals/core-routing-v1.1.0-2026-08-28.md).
+Do not mix scores across changed inventories, prompts or rubrics.
+
+## 4. Client runtime acceptance
+
+A client becomes runtime-verified only after a clean-session transcript proves
+discovery and correct first actions. Follow
+[`COMPATIBILITY.md`](COMPATIBILITY.md). Marketplace publication, production
+behavior and buyer usefulness each require their own readback.
+
+For a long-running probe, read back `SESSION_HEALTH_GATE` at `START`,
+`AFTER_COMPACTION`, `MATERIAL_TRANSITION` and `BEFORE_CLOSEOUT`, including the
+host policy and actual signal values. Read back `RUNTIME_RELEASE` separately;
+`task_complete` is not evidence that task-owned browser, tool or subprocess
+workers ended. A missing capability is `UNKNOWN` or `UNSUPPORTED`, lowers the
+runtime proof, and must not be reported as a clean-runtime pass. Missing optional telemetry
+does not block safe artifact delivery; missing enforcement of an explicitly
+required hard budget blocks only work that depends on that guarantee.
+Native goals are optional and require the host tool's authorization; a Markdown
+goal is sufficient. Before a host clear, persist and read back `GOAL_FILE`, verify no task-owned
+writer remains, record `CLEAR_MODE`, then prove clear completion. Start a fresh
+turn by reading the same goal file and reconciling repository, checkout, state
+and next safe action; transcript text alone is not recovery evidence.
+
+For Codex, test explicit invocation with the name the client lists for the module
+(`$nobrainer-tech-flow:nobrainer-tech-flow` when it lists modules under the plugin
+name, `$nobrainer-tech-flow` when it lists them plainly; the other form adds no
+module text) and test plain aliases separately as implicit-routing controls. Bind
+the transcript to the exact installed skill hash and disable same-name user copies
+in an isolated probe; two skills with the same name are not merged. An alias
+failure must not be reported as a source-isolated behavior result.
+
+Model-policy tests prove the portable `STANDARD`, `EXTENDED` and `ROUTED`
+contract, including the no-silent-switch rule. They do not prove that a client
+actually selects a provider model. That requires a clean-session readback of
+requested versus actual model, effort, budget and escalation behavior.
+
+## Release gate
+
+A releasable commit requires:
+
+- all deterministic checks green on the exact commit;
+- no unresolved P0/P1 review finding;
+- a public-clean and secret scan;
+- a recorded behavior holdout for changed workflow controls;
+- a review-failure scenario proving the route returns to Build with invalidated
+  evidence;
+- a public-surface coherence check: every affected README, doc, template and
+  diagram is updated and read back, or `NOT_NEEDED` is recorded with a reason;
+  flow changes refresh both the SVG and README Mermaid chart;
+- honest compatibility labels;
+- model names and marketing remain workflow-positioning claims unless direct
+  runtime evidence exists;
+- a rollback path;
+- owner approval for merge and publication.
+
+Scan the exact staged candidate with:
+
+```bash
+gitleaks git --pre-commit --staged --redact --no-banner --ignore-gitleaks-allow
+```
+
+A full-history finding is a separate history-remediation decision. Investigate
+it explicitly; do not hide it behind a broad allowlist or treat it as proof that
+the staged candidate introduced a secret.
+
+## Session restart
+
+`tests/test_restart_gate.py` invokes the shipped helper rather than a test-only
+copy. It covers startup-cost payback, unknown economics, repeated restart without
+progress, consent, unknown writers, stale checkpoints/ACKs, uncertain transport,
+unsupported transfer and archive/takeover ordering. These are decision-level
+tests; no real session is created or archived by the helper.
+
+Native-adapter acceptance additionally requires an actual fresh target, visible
+read-only ACK, authoritative conditional transfer, target takeover and exact old
+session archive readback. Include a competing trigger and interrupted create.
+Measure accepted work and total input/output/compaction/recovery usage before
+and after; deterministic decisions do not establish token or quality gains.
+
+
+## 2.1.0 idea intake and plain technical English
+
+The [2.1.0 record](releases/v2.1.0.md) separates instruction review, bounded
+same-session writing exercises, repository tests and public release readback.
+The baseline already followed an explicitly requested SDD/end-to-end path;
+this release does not claim a measured behavioral gain from making it explicit.
+A formal ASD-STE100 audit, clean-session client discovery and comparative model
+cost/speed tests remain outside this evidence.
+
+
+## 2.2.0 presentation and closeout
+
+The [2.2.0 record](releases/v2.2.0.md) binds fresh Codex/Claude print runs to
+the exact communication reference and retains synthetic prompts and responses.
+These are explicit-source behavior slices. Host-executed artifact checks do not
+prove automatic discovery or autonomous whole-task execution in either client.