nobrainer-tech-flow 0.0.0-stage → 2.4.0

package/docs/releases/v2.3.1.md

@@ -0,0 +1,71 @@
+# nobrainer-tech-flow 2.3.1: keep your skills under retired names
+
+Release date: 2026-10-13.
+
+Keep your own skill under a name Flow retired and still install or update Flow.
+For example, a private `nobrainer-reddit` no longer stops the Python or shell
+installer. Both leave the existing file, directory or symlink unchanged through
+apply, repeat and undo. `install_skills.py` and `install.sh` report it as
+`PRESERVED_FOREIGN`; the guided `install.py` and npm setups continue without a
+separate line.
+
+## What changes
+
+- `nobrainer-reddit` is explicitly classified as retired. Flow removed the old
+  Reddit CLI rather than absorbing its functionality or trigger into an active
+  skill. Another source can legitimately use that name.
+- Foreign targets at renamed or absorbed aliases such as `nb-flow` still stop
+  installation, so an existing skill cannot silently shadow a Flow trigger.
+  Unresolved legacy names such as `nobrainer-fast-audit` also remain conflicts.
+- Exact old links owned by the same checkout still require `--migrate-legacy`.
+  Migration continues to preserve their recovery backups.
+
+This behavior applies to `install_skills.py`, the Python/npm setups that call
+it and the no-Python `install.sh`. Both installers compare an old link against
+the exact predecessor paths owned by the same checkout. See
+[conflict and migration behavior](../INSTALL.md#conflict-and-migration-behavior).
+
+## Verification record
+
+Local checks on the installer and 2.3.1 metadata (macOS, Python 3.14.5):
+
+- `python3 scripts/validate_skills.py` and
+  `python3 scripts/validate_skills.py --suite`: both passed.
+- `python3 -m unittest tests.test_installer -v`: 55 tests passed. The new cases
+  preserve foreign symlinks, directories and files at the retired name, retain
+  exact owned-link migration and reject foreign `nb-flow` targets.
+- `python3 -m unittest tests.test_shell_installer -v`: 40 tests passed with
+  `/bin/sh`, dash, bash in POSIX mode and zsh emulating sh.
+- `python3 -m unittest discover -s tests -v`: 412 tests ran; all passed except
+  2 platform-specific skips. This includes the exported-source acceptance check
+  without Git metadata.
+- Shell checks run in every available POSIX shell and compare exact-link
+  classification with Python for absolute, relative and chained old links,
+  links to other current skills, loops and targets with trailing newlines. The
+  no-Python check also exercises retired-name preservation.
+- An isolated Python setup preview, apply and undo preserved a foreign retired
+  file's bytes and inode. A mixed retired-name/renamed-alias check still refused
+  installation before any canonical write.
+- The changed Python files compiled, and the npm command read back `2.3.1`.
+- A current-tree secret scan with the repository's gitleaks configuration found
+  no leaks.
+
+These checks prove local installer behavior and package metadata. They do not
+prove publication, a fresh target-client import or a performance gain.
+
+## Scope and distribution
+
+This is an installer-only fix. The eighteen skill contents are unchanged from
+v2.3.0 except for the entry skill's `VERSION` file. No workflow, model-routing or
+performance change is claimed.
+
+The native plugin 2.3.1 will carry the same installer. Plugin export, publication
+and target-client import each require their own readback. npm registry
+publication is still pending; source release files and a locally packed tarball
+do not establish registry availability.
+
+## Rollback
+
+Return to the reviewed v2.3.0 source through the documented preview and undo
+flow. Keep retained source files while any client links refer to them. A foreign
+retired target needs no restoration because this patch leaves it unchanged.

package/docs/releases/v2.3.2.md

@@ -0,0 +1,242 @@
+# nobrainer-tech-flow 2.3.2: install, update and undo without false alarms or leftovers
+
+Release date: 2026-10-18.
+
+Run undo twice and the second run no longer fails. Undo leaves your profile as it was
+before the setup, including the empty folders the installer had to create. An update
+through `install.sh` delivers the new instruction block. A repeat apply says that
+nothing changed instead of asking you to restart your client. These six fixes came
+from a test of a fresh install that followed the README commands on 2.3.1. A review of
+them and a Windows test run found the further fixes listed after them: undo now also
+works after you edit the instruction file, the default block no longer names a private
+skill, the npm release copy moves out of the folder a Git clone may use, and the
+Windows hook wrapper no longer runs a `bash.exe` from the current folder.
+
+## What changes
+
+- **A second undo is a clear no-op.** `--undo` and `--undo --apply` with no setup
+  record print `NOTHING TO UNDO`, name the client and the record they looked for,
+  write nothing and exit 0, in `install.sh`, `install.py` and the npm command. In
+  2.3.1 they exited 3 with `rollback state not found`. A damaged or unreadable
+  record, a folder or link where the record should be, and a record that only the
+  Python undo can read still stop with an error. So does a record in a folder this
+  account cannot search, such as a home without search permission while
+  `CLAUDE_CONFIG_DIR` points elsewhere: undo exits 3 instead of `NOTHING TO UNDO`.
+- **Undo removes the folders the setup created.** The setup record gains
+  `created_dirs`, the folders the setup had to create (links resolved, an empty list
+  included). Undo removes each one that is still empty, deepest first. A folder that
+  existed before the setup, or holds anything else, stays. A record from 2.3.1 or
+  earlier has no list and keeps the earlier rule, so its undo removes only an empty
+  skills folder. A list that names a folder the setup cannot have made (a relative
+  path, `..`, the root, a folder beside the setup's own, a duplicate, an entry that
+  is not text) is refused with exit 3 and nothing is changed. The `.bak` copy the
+  setup made of an instruction file you already had is kept, as before.
+- **`install.sh` replaces a block of an earlier version.** When the managed block
+  differs from this version's text, `install.sh` replaces it from the start marker to
+  the end marker and keeps every byte outside them (line endings, a byte order mark,
+  a missing final line break). The file as it was is saved as a `.bak` copy first,
+  the preview shows the lines that change, and undo still removes the block or puts
+  back the file from before the setup. A block that carries an option (a standing
+  authorization, a saved wiki root or a preference), or whose markers do not stand on
+  lines of their own, is still left as it is with a note that points to
+  `install_personalization.py --keep-options`; `install.py` keeps rewriting such
+  blocks and keeping their options.
+- **The block names the module the way the client lists it.** Codex 0.157.1 lists the
+  module as `nobrainer-tech-flow:nobrainer-tech-flow` when a plugin manifest sits
+  above the folder a link resolves to, which is the case for a git checkout and for the
+  npm package, and as `nobrainer-tech-flow` for a copy. It adds the module text to the
+  request only for the name it lists. The entrypoint line of the block and the install,
+  naming, testing and compatibility docs now say to use the listed name and give both
+  Codex forms. The README and the repository instruction files (`AGENTS.md` and
+  `CLAUDE.md`) give the same rule. Existing blocks differ from the new text, so the
+  next apply updates them (`install.sh` through the replacement above, `install.py`
+  as before).
+- **A repeat apply says nothing changed.** When no link and no instruction file was
+  written, apply prints `UP TO DATE` and no restart hint. `INSTALLED` and the restart
+  hint stay for a run that changed something.
+- **The setup record and file modes are documented.** The installer writes
+  `.nobrainer-flow-onboarding-<client>.json` in the chosen home with mode 0600. A new
+  instruction file is created with mode 0600 as well; an existing file keeps its mode
+  and so does its `.bak` copy. `install.sh` now also updates a read-only file (mode
+  0444) and leaves it read-only, as the Python installer already did; it used to stop
+  with exit 4. When the setup record cannot be saved, the run puts such a file back as it was
+  instead of leaving the new block behind. Its undo takes the block out of such a file the same way and leaves it
+  read-only; it used to stop with exit 4 after removing the links. Undo deletes the record. [Installation](../INSTALL.md)
+  describes the file and its fields.
+
+- **Undo removes the skill links even after you edited the instruction file.** In
+  2.3.1 an edit to the instruction file after the setup made undo stop with exit 3
+  before it unlinked anything. Now `install.sh`, `install.py`, the npm command and the
+  guided `--rollback` remove the links the setup made, print `PARTLY UNDONE`, leave the
+  edited file exactly as it is (managed block included) and still exit 3. The record
+  stays, with no links in it, and a hint says how to take the block out as well: apply
+  again, which records the file as it is now, then undo again; your edits outside the
+  block stay. Deleting the lines between the markers by hand works too: when the file
+  holds neither marker any more, the next undo finishes, deletes the record and the
+  empty folders the setup made, and leaves the file as it is. A missing `.bak` copy no
+  longer stops the undo of an edited file, since that file does not get the block back;
+  `install.sh` and the guided undo used to stop on it before unlinking anything. With
+  that copy gone or unreadable, the hint offers only the removal by hand, because
+  applying again keeps that copy in the record and the undo after it would stop on it. A link
+  that changed since the setup still stops the undo before anything changes. So does
+  an instruction file or `.bak` copy the undo cannot read: both undos stop with exit 3
+  and an `ERROR: cannot read` line before removing a link or the record. `install.sh`
+  used to take an unreadable file for one without the block, remove every link and
+  delete the record while the block stayed.
+- **The default block no longer names a private skill.** The last line of the block
+  told every user to load `nobrainer-ak` (`nbak`), which is not one of the eighteen
+  modules. It now reads: use `nobrainer-writing` for material writing when available,
+  with the same guidance on technical documentation, facts, language and verification.
+  A block written by 2.3.1 is still recognised as a Flow-managed block of an earlier
+  version: the next apply replaces it (through `install.sh` only when the block holds
+  no option; `install.py` always, keeping its options), and undo gives back the file
+  from before.
+- **npm keeps its release copy beside `~/.nobrainer-tech-flow`, not inside it.** The
+  npm command now copies the release to `~/.nobrainer-tech-flow-npm/<version>` (under
+  `--home` when given). The README suggests a Git clone in `~/.nobrainer-tech-flow`,
+  and a `git clean -fdx` there deleted the copy that the skill links point to. No
+  published release wrote the new folder before; an undo that finds only an earlier
+  release's copy in `.nobrainer-tech-flow/npm` says so and asks you to undo with the
+  release that made the setup.
+- **The Windows hook wrapper finds Git Bash safely.** `hooks/run-hook.cmd` looks for
+  Git Bash in its install folders (`%ProgramFiles%`, `%ProgramFiles(x86)%`,
+  `%LOCALAPPDATA%\Programs`), then beside the `git.exe` on PATH, then for `bash.exe`
+  in the PATH folders only. It no longer runs a `bash.exe` from the current folder. It
+  returns the hook's own exit code; it used to report the code from before bash ran.
+  Without bash it prints a message on stderr and exits 1, as `session-start` does when
+  it cannot add the bootstrap, so the client reports a hook error that blocks nothing
+  and the session continues.
+- **Undo handles damaged or rearranged profiles more safely.** A folder in the record
+  that now lies under a link (for example `~/.config` replaced by a link after the
+  setup) is left where the link points, with a `PRESERVED` line; both undos used to
+  remove empty folders of the same name in the other tree. A home that did not exist
+  and was made only to hold the record, because `CLAUDE_CONFIG_DIR` or
+  `XDG_CONFIG_HOME` put the skills elsewhere, is now listed and removed by undo.
+  That home is made before anything else is written, so when it cannot be made the setup
+  stops without leaving links or a block that no record describes. A repeat apply keeps the folders an earlier run recorded as they were
+  recorded; it used to resolve them again, so a folder swapped for a link to another
+  tree passed that tree's folders to the undo, which removed them. A client variable
+  that reaches an existing folder through one that does not exist yet (for example
+  `CLAUDE_CONFIG_DIR=profile/missing/../config`) no longer gets that existing folder
+  recorded as made by the setup, so the undo removes `missing` and `config` and keeps
+  `profile`.
+  `install.sh` treats a dangling link in place of the older
+  `.nobrainer-flow-onboarding.json` as a damaged record and stops with exit 3 instead
+  of `NOTHING TO UNDO`, and a record that names a path without a leading slash is
+  refused as damaged with exit 3; `install.sh` used to hang on it. On Windows the guided
+  undo treats a directory junction like a link and leaves it, with the folder it points
+  to; it used to remove the junction. The npm undo looks for a record before it inspects the retained
+  copy, so a partial or changed copy no longer blocks the `NOTHING TO UNDO` no-op. In
+  Git Bash a recorded folder with `..` is refused as in the other installers; `cygpath`
+  used to remove the `..` before the check. The Windows smoke tests also compare the
+  paths Git Bash prints by their end, since it spells them its own way.
+
+Both installers behave the same. The scripts, the npm command that calls
+`install.py` and the guided `--rollback` read and write one record.
+
+### Instruction fixes
+
+Five instruction fixes from a review of 2.3.1 also ship. The README leads with the
+Git install while the npm package is unpublished. Flow owns one corrective-attempt
+budget (two attempts per observed failure), and Build and RCA link to it instead of
+saying three. Dispatcher accepts the worker ID a host returns for a hidden native
+worker as the send receipt, so default delegation can be dispatched; visible sessions
+still go through Sessions. Saying "Use NBFlow" turns on session health observation
+only: a restart or archive needs separate owner consent, and the quick path skips
+startup care. Stale status lines, an undefined "team cap" and two lifecycle names are
+corrected, and every approval-gate list includes contacting people.
+
+## Verification record
+
+Local checks on the installer and 2.3.2 metadata (macOS, Python 3.14.5):
+
+- `python3 scripts/validate_skills.py` and
+  `python3 scripts/validate_skills.py --suite`: both passed.
+- `python3 -m unittest tests.test_shell_installer -v`: 55 tests passed with
+  `/bin/sh`, dash, bash in POSIX mode and zsh emulating sh. The new cases cover the
+  second undo, the folder list, the block replacement (CRLF line endings, a byte
+  order mark and a missing final line break included), the `UP TO DATE` message
+  and the file modes, and check that undo gives back the profile as it was.
+- `tests.test_installer` (55 tests), `tests.test_one_command_installer` (29),
+  `tests.test_personalization` (36), `tests.test_guided_onboarding` (30, 1 skipped) and
+  `tests.test_npm_distribution` (7) passed.
+- `python3 -m unittest discover -s tests -v`: 434 tests ran in 1261 seconds; all
+  passed except 2 platform-specific skips. This includes the exported-source
+  acceptance check without Git metadata.
+- An end-to-end run of the 2.3.1 and the 2.3.2 scripts in disposable homes, under
+  a macOS sandbox that allowed writes only to a scratch folder and no network: 44
+  scenarios and 186 installer runs for Codex and OpenCode, with `install.sh`,
+  `install.py` and the npm command, on an empty profile and on one that already had
+  a mode 0640 instruction file. With 2.3.2, apply, apply again (`UP TO DATE`, no
+  restart hint), undo (the profile equal to the starting one apart from the kept
+  `.bak` copy, and no `~/.agents` or `~/.config/opencode` left) and a second undo
+  (`NOTHING TO UNDO`, exit 0, writes to the home denied by the sandbox) behaved as
+  described in all 8 combinations. The same scenarios on 2.3.1 ended the second
+  undo with exit 3, and undo left the empty folders in the 6 combinations where
+  the setup had created them. Updating a 2.3.1 setup in place with 2.3.2 replaced
+  the block in all 4 runs with every other byte unchanged, and undo gave back the
+  file from before the setup. A non-empty `~/.agents` stayed after undo.
+- Syntax checks of `scripts/install.sh` in the four shells and `shellcheck -S error`
+  passed. The changed Python files compiled, and the npm command read back
+  `2.3.2`.
+- A readback of how Codex 0.157.1 names and loads the module, with no model
+  involved, as described in the compatibility record below.
+- A current-tree secret scan with the repository's gitleaks configuration found
+  no leaks.
+
+After the review fixes (macOS, Python 3.14.5):
+
+- `python3 scripts/validate_skills.py` and `--suite`: both passed.
+- `python3 -m unittest discover -s tests`: 443 tests ran; all passed except 4
+  platform-specific skips. The new regression tests that run on macOS failed on the
+  code before their fixes, except the check of the hook wrapper's shell half, which was
+  already correct.
+- `bash -n`, `sh -n` and `dash -n` on `scripts/install.sh` and `hooks/run-hook.cmd`, and
+  `shellcheck -S error` on `scripts/install.sh`, passed.
+- The batch half of `hooks/run-hook.cmd` and the Git Bash path checks run only on
+  Windows; the Windows smoke job in CI is their proof, not this local run.
+
+After the undo review fixes (macOS, Python 3.14.5):
+
+- `python3 -m unittest tests.test_shell_installer tests.test_installer
+  tests.test_one_command_installer`: 150 tests passed. `tests.test_guided_onboarding`
+  and `tests.test_personalization`: 67 tests passed, 1 skipped. The three new checks
+  (a folder reached through `..`, an unreadable instruction file or backup, and the
+  undo of a read-only file) failed on the code before their fixes in 9 subtests.
+- `python3 scripts/validate_skills.py` and `--suite`, `bash -n`, `sh -n` and `dash -n`
+  on `scripts/install.sh`, `shellcheck -S error` and `git diff --check`: all passed.
+
+These checks prove local installer behavior and package metadata. They do not
+prove publication, a fresh target-client import or a performance gain.
+
+## Scope and distribution
+
+This is an installer, documentation and instruction-consistency fix. The module set
+stays at eighteen; module text changes only where the instruction fixes above resolve
+a contradiction. No model-routing or performance change is claimed.
+
+Two limits remain. The guided `recommend_flow_setup.py --rollback` with no record
+still exits 3 with `rollback state not found`, and an npm undo that finds a record but
+no retained release files still exits 3. Neither is part of the second-undo case.
+
+The Codex naming check covers Codex 0.157.1 on macOS, with a typed name and a linked
+mention sent through `codex exec` to a local stand-in server. It does not show what a
+model does when it sees the plain form in a listing that names the module under the
+plugin, and it did not drive the terminal or desktop mention pickers, other Codex
+versions or operating systems, or a plugin-channel install. The
+[compatibility record](../COMPATIBILITY.md) has the readback.
+
+The native plugin 2.3.2 will carry the same installer. Plugin export, publication and
+target-client import each require their own readback. npm registry publication is
+still pending; source release files and a locally packed tarball do not establish
+registry availability.
+
+## Rollback
+
+Return to the reviewed v2.3.1 source through the documented preview and undo flow.
+Undo a 2.3.2 setup with 2.3.2 scripts when you can. The 2.3.1 `install.sh` cannot read
+a 2.3.2 record and points you to the Python undo. That undo reads the record and
+removes the links, the block and the record, but it does not know the folder list, so
+the empty folders the setup created stay. A setup recorded by 2.3.1 and undone by
+2.3.2 leaves them too, because its record has no folder list. Keep retained source
+files while any client links refer to them.

package/docs/releases/v2.4.0.md

@@ -0,0 +1,126 @@
+# nobrainer-tech-flow 2.4.0: ask before risky commands, and see whether the proof still matches
+
+Release date: 2026-10-19.
+
+nobrainer-tech-flow can ask before risky commands and shows whether its proof still
+matches your files. The guards are optional and Claude Code only. The rest is
+instruction and helper changes for every client.
+
+## What changes
+
+### Optional Claude Code guards
+
+`scripts/install.py --client claude --guards` previews, then with `--apply` adds hooks to
+the Claude Code user settings. The preview names only the hooks it would add or remove
+and the settings path, never other settings. `--undo --apply` removes only hooks whose
+command is exactly one the installer generates. Each change keeps a new backup file, readable
+only by you, and never overwrites an existing one. The hooks run
+`skills/nobrainer-tech-flow/scripts/flow_guard.py` through the skill link.
+
+- PreToolUse asks before `rm -r` (also `/bin/rm`) outside temporary folders,
+  `git push --force`, `-f`, `--force-with-lease` or a `+branch` refspec,
+  `git reset --hard`, `git clean -f`, `vercel --prod`, `npm publish`,
+  `terraform apply` or `destroy`, `kubectl delete` and `gh release create`, also with
+  global options before the subcommand (`git -C dir push -f`, `npm -w pkg publish`,
+  `terraform -chdir=infra apply`, `kubectl -n prod delete`, `gh -R owner/repo release
+  create`). A relative `rm` target counts as temporary only when the session's working
+  folder is temporary and the command does not change folder first, and a path counts
+  by where its links lead, so a temporary folder that links to a project is the project.
+  An `rm -r` whose arguments it cannot read, and a single command line too long to check
+  (over 2,000 characters) that names one of these tools, are asked about as well. It
+  asks; it never denies.
+- Stop and SubagentStop block once when a turn that changed files or ran commands ends
+  with no `Proof:` or `Checked:` line and no `UNVERIFIED`.
+- Both fail open on input they cannot read. They are off by default, POSIX only in this
+  version, and the plugin hooks stay SessionStart only.
+- Limits: the guard reads command text. A command behind `sh -c`, a variable or an alias
+  can pass, other tools such as `pnpm publish` are not matched, and a risky phrase inside
+  a quoted string can ask without need. It is a seatbelt, not a security boundary.
+
+### Evidence receipts
+
+`skills/nobrainer-sessions/scripts/evidence_receipt.py` runs one command through the
+bounded runner and records a declared input scope before and after. `check` reports
+`CURRENT`, `STALE`, `CHANGED_DURING_RUN` or `UNAVAILABLE` without re-running anything.
+Python 3.11+ and POSIX only; receipts are unsigned and output is stored unredacted. See
+[the reference](../../skills/nobrainer-sessions/references/evidence-receipt.md).
+
+The closeout now carries `current for <input snapshot/time or UNKNOWN>`, and a worker's
+`RETURN` line starts with the outcome as the worker understood it.
+
+### Proof contract
+
+- Build reports `TEST_SENSITIVITY: PROVEN | PARTLY_PROVEN | NOT_PROVEN | NOT_APPLICABLE`
+  for a behavior-preserving rewrite, after seeding one deliberate fault per changed
+  behavior class. `NOT_PROVEN` leaves the preservation claim `UNVERIFIED`.
+- Review keeps a "no behavior change" claim open when `TEST_SENSITIVITY` is missing or
+  `NOT_PROVEN`, and does not accept `STALE` or `CHANGED_DURING_RUN` evidence as proof of
+  the current artifact.
+- Model routing: routine units get the lowest effort that still meets acceptance, workers
+  share an assignment prefix with the unit-specific part last (cache reuse is plausible
+  but unmeasured), and a unit that reaches its `BUDGET` stops and reports partial results.
+- Security: a plaintext `.env` or credential file in a workspace an agent can read counts
+  as secret exposure.
+- Correction hooks: a deterministic failure that a native check can catch gets that check
+  as the prevention; a prose rule only when no mechanism fits.
+
+### Instruction debt and one session rule
+
+Skill doctor gains a `REPORT_ONLY` instruction-debt audit. `context_candidates.py` reads
+an owner-supplied, redacted history JSON and proposes repeated instructions with the
+history rows they came from; the audit maps accepted candidates to exact `file:line`,
+and the owner approves each change. The visible-session rule now has
+one canonical home in the entry module, and the Dispatcher and Team modules link to it
+instead of restating it.
+
+### Distribution
+
+- The README first screen leads with the Claude Code and Codex plugin installs, then the
+  Git install for any client.
+- The Codex marketplace is renamed `nobrainer-tech-skills-dev` -> `nobrainer-tech`, like
+  the Claude one. If you added it under the old name, follow the
+  [migration guide](../MIGRATION_TO_FLOW.md) to remove it and add it again; otherwise the
+  old and new plugin stay enabled side by side.
+- Manifests describe one workflow of 18 modules that ends with an evidence handoff.
+- The npm package is still not published on npm. The `npx` commands in
+  [INSTALL.md](../INSTALL.md#npm-command) work only after publication.
+
+## Verification record
+
+Live client run on 2026-10-18: the guards on Claude Code 2.1.302 with temporary
+`--settings` in a throwaway sandbox. The Stop hook blocked once and the agent added a
+`Proof:` line. The PreToolUse "ask" fired for `git push --force` in default and
+`bypassPermissions` modes; in `-p` mode, where nobody can answer, it became a denial.
+
+Local checks on this checkout (macOS, Python 3.14.5):
+
+- `python3 scripts/validate_skills.py` and `python3 scripts/validate_skills.py --suite`:
+  both passed.
+- `tests.test_adapters`, `tests.test_suite`, `tests.test_npm_distribution` and
+  `tests.test_update_check`: 101 tests passed, run without the one test that starts a
+  nested full discovery.
+- `python3 -m unittest discover -s tests` on the final commit: 514 tests passed with 5
+  platform-specific skips.
+- Two independent review rounds on the whole change, then repeated reviews of the guard,
+  the settings backup and the receipts; every finding is fixed with a test that failed
+  before the fix.
+- `git diff --check` and a staged-change secret scan with the repository's gitleaks
+  configuration found nothing.
+
+These checks prove local behavior and package metadata. They do not prove publication,
+a fresh target-client import or a performance gain.
+
+## Scope and distribution
+
+No benchmark was run and no model is imposed. The module set stays at eighteen. The
+native plugin 2.4.0 will carry the same files; plugin export, publication and
+target-client import each need their own readback. npm registry publication is still
+pending; source release files and a locally packed tarball do not establish registry
+availability.
+
+## Rollback
+
+Return to the reviewed v2.3.2 source through the documented preview and undo flow. Remove
+the guards first with `scripts/install.py --client claude --guards --undo --apply`; they
+point at the skill link, so an old checkout leaves them doing nothing. A Codex user who
+moved to the new marketplace name keeps it, or removes it and re-adds the old name.

package/gemini-extension.json

@@ -0,0 +1,6 @@
+{
+  "name": "nobrainer-tech-flow",
+  "description": "From task to done. nobrainer-tech-flow is one workflow of 18 modules for AI coding agents: it scopes the task, delegates ready work, checks the result and hands over the evidence, including what was not checked.",
+  "version": "2.4.0",
+  "contextFileName": "GEMINI.md"
+}

package/hooks/claude-hooks.json

@@ -0,0 +1,17 @@
+{
+  "hooks": {
+    "SessionStart": [
+      {
+        "matcher": "startup|resume|clear|compact|fork",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}/hooks/run-hook.cmd\" session-start",
+            "shell": "bash",
+            "async": false
+          }
+        ]
+      }
+    ]
+  }
+}

package/hooks/hooks-cursor.json

@@ -0,0 +1,10 @@
+{
+  "version": 1,
+  "hooks": {
+    "sessionStart": [
+      {
+        "command": "\"${CURSOR_PLUGIN_ROOT}/hooks/run-hook.cmd\" session-start"
+      }
+    ]
+  }
+}

package/hooks/run-hook.cmd

@@ -0,0 +1,36 @@
+: << 'CMDBLOCK'
+@echo off
+setlocal
+if "%~1"=="" (
+  1>&2 echo run-hook.cmd: missing hook script name
+  exit /b 1
+)
+set "HOOK_DIR=%~dp0"
+set "HOOK_BASH="
+set "HOOK_GIT="
+rem Git Bash from its install folders, or beside the git.exe on PATH. Never a bare "bash",
+rem nor the PATH modifier of a for variable: both try the current folder first, where anyone
+rem could have put a bash.exe. Each PATH folder is checked by name instead. No labels: goto
+rem can miss a label in a file with LF line breaks.
+if defined ProgramFiles if exist "%ProgramFiles%\Git\bin\bash.exe" set "HOOK_BASH=%ProgramFiles%\Git\bin\bash.exe"
+if not defined HOOK_BASH if defined ProgramFiles(x86) if exist "%ProgramFiles(x86)%\Git\bin\bash.exe" set "HOOK_BASH=%ProgramFiles(x86)%\Git\bin\bash.exe"
+if not defined HOOK_BASH if defined LOCALAPPDATA if exist "%LOCALAPPDATA%\Programs\Git\bin\bash.exe" set "HOOK_BASH=%LOCALAPPDATA%\Programs\Git\bin\bash.exe"
+if not defined HOOK_BASH if defined PATH for %%P in ("%PATH:;=" "%") do if not defined HOOK_GIT if not "%%~P"=="" if exist "%%~P\git.exe" set "HOOK_GIT=%%~P\git.exe"
+if defined HOOK_GIT for %%D in ("%HOOK_GIT%\..\..") do if exist "%%~fD\bin\bash.exe" set "HOOK_BASH=%%~fD\bin\bash.exe"
+if not defined HOOK_BASH if defined PATH for %%P in ("%PATH:;=" "%") do if not defined HOOK_BASH if not "%%~P"=="" if exist "%%~P\bash.exe" set "HOOK_BASH=%%~P\bash.exe"
+rem Without bash, exit 1 as session-start does when it cannot add the bootstrap: the client
+rem reports a hook error that blocks nothing, and the session goes on.
+if not defined HOOK_BASH (
+  1>&2 echo nobrainer-tech-flow: the session hook needs Git Bash, which was not found. Install Git for Windows from https://git-scm.com/download/win. This session continues without the Flow bootstrap.
+  exit /b 1
+)
+"%HOOK_BASH%" "%HOOK_DIR%%~1" %2 %3 %4 %5 %6 %7 %8 %9
+rem On a line of its own: inside a parenthesised block ERRORLEVEL is read before bash runs.
+exit /b %ERRORLEVEL%
+CMDBLOCK
+
+set -e
+script_dir="$(cd "$(dirname "$0")" && pwd)"
+script_name="${1:?missing hook script name}"
+shift
+exec bash "${script_dir}/${script_name}" "$@"

package/hooks/session-start

@@ -0,0 +1,38 @@
+#!/usr/bin/env bash
+
+set -euo pipefail
+
+script_path="${BASH_SOURCE[0]:-$0}"
+case "${OSTYPE:-}" in
+  # Windows hosts may pass a backslash path; dirname only splits on slashes.
+  msys* | cygwin* | win32*) script_path="${script_path//\\//}" ;;
+esac
+script_dir="$(cd "$(dirname "${script_path}")" && pwd)"
+plugin_root="$(cd "${script_dir}/.." && pwd)"
+bootstrap_path="${plugin_root}/adapters/bootstrap.md"
+
+if [ ! -f "$bootstrap_path" ]; then
+  printf 'NoBrainer hook: missing adapters/bootstrap.md\n' >&2
+  exit 1
+fi
+
+escape_for_json() {
+  local value="$1"
+  value="${value//\\/\\\\}"
+  value="${value//\"/\\\"}"
+  value="${value//$'\n'/\\n}"
+  value="${value//$'\r'/\\r}"
+  value="${value//$'\t'/\\t}"
+  printf '%s' "$value"
+}
+
+session_context="$(escape_for_json "$(<"$bootstrap_path")")"
+
+if [ -n "${CURSOR_PLUGIN_ROOT:-}" ]; then
+  printf '{"additional_context":"%s"}\n' "$session_context"
+elif [ -n "${CLAUDE_PLUGIN_ROOT:-}" ]; then
+  printf '{"hookSpecificOutput":{"hookEventName":"SessionStart","additionalContext":"%s"}}\n' "$session_context"
+else
+  printf 'NoBrainer hook: unsupported SessionStart host\n' >&2
+  exit 1
+fi

package/package.json

@@ -1,6 +1,71 @@
 {
   "name": "nobrainer-tech-flow",
-  "version": "0.0.0-stage",
-  "stub": true,
-  "description": "Temporary package placeholder for staged publishing"
-}
+  "version": "2.4.0",
+  "description": "From task to done. nobrainer-tech-flow is one workflow of 18 modules for AI coding agents: it scopes the task, delegates ready work, checks the result and hands over the evidence, including what was not checked.",
+  "type": "module",
+  "main": ".opencode/plugins/nobrainer-tech-skills.js",
+  "keywords": [
+    "agent-skills",
+    "agentic-workflows",
+    "claude-code",
+    "codex",
+    "verification",
+    "spec-driven-development",
+    "multi-agent",
+    "cursor",
+    "gemini-cli",
+    "opencode",
+    "pi-package"
+  ],
+  "pi": {
+    "extensions": [
+      "./.pi/extensions/nobrainer-tech-skills.js"
+    ],
+    "skills": [
+      "./skills"
+    ]
+  },
+  "license": "MIT",
+  "bin": {
+    "nobrainer-tech-flow": "bin/nobrainer-tech-flow.mjs"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/nobrainer-tech/nobrainer-tech-flow.git"
+  },
+  "homepage": "https://nobrainer.tech/flow/",
+  "bugs": {
+    "url": "https://github.com/nobrainer-tech/nobrainer-tech-flow/issues"
+  },
+  "engines": {
+    "node": ">=18"
+  },
+  "files": [
+    "bin/",
+    "skills/",
+    "scripts/",
+    "adapters/",
+    ".opencode/",
+    ".pi/",
+    ".codex-plugin/",
+    ".claude-plugin/",
+    ".agents/plugins/",
+    "plugin.json",
+    "gemini-extension.json",
+    "README.md",
+    "LICENSE",
+    "SECURITY.md",
+    "AGENTS.md",
+    "CLAUDE.md",
+    "CONTRIBUTING.md",
+    "GEMINI.md",
+    "docs/*.md",
+    "docs/releases/*.md",
+    "hooks/",
+    "assets/*.svg",
+    "assets/*.png"
+  ],
+  "publishConfig": {
+    "access": "public"
+  }
+}