briefops 2.1.2 → 2.1.3

package/CHANGELOG.md

@@ -4,6 +4,11 @@
 
 - No changes yet.
 
+## 2.1.3 - 2026-07-05
+
+- Add lightweight utility evaluation documentation and example eval logs.
+- Refresh the npm lockfile after dependency update with zero reported audit vulnerabilities.
+
 ## 2.1.2 - 2026-07-01
 
 - Add an explicit BriefOps environment gate to generated startup guidance so missing `briefops` on `PATH` becomes `Status: setup-required` instead of a silently skipped prime step.

package/README.md

@@ -46,7 +46,7 @@ BriefOps can generate Codex skill-plugin assets, but the plugin calls the local
 
 ## Release Status
 
-BriefOps 2.1.2 is the current npm-ready release for developers who want a local-first memory and context ledger for AI coding agents. It packages the 2.1 Master Harness routing, continuity observability, strict release-readiness checks, evidence anchors, workspace-lock hardening, and the fresh-thread environment gate that treats missing local CLI setup as `Status: setup-required`.
+BriefOps 2.1.3 is the current npm-ready release for developers who want a local-first memory and context ledger for AI coding agents. It packages the 2.1 Master Harness routing, continuity observability, strict release-readiness checks, evidence anchors, workspace-lock hardening, the fresh-thread environment gate that treats missing local CLI setup as `Status: setup-required`, and lightweight local utility evaluation docs.
 
 The public CLI behavior and workspace file-format policy are documented in `docs/compatibility.md` and `docs/file-format.md`. The core safety principles are stable:
 
@@ -59,7 +59,7 @@ The public CLI behavior and workspace file-format policy are documented in `docs
 
 For privacy guarantees, see `docs/privacy-model.md`.
 
-## Open Source Trust Boundary
+## Publishing And Sharing Boundary
 
 Before publishing a repository or sharing generated context, review:
 
@@ -69,6 +69,13 @@ Before publishing a repository or sharing generated context, review:
 - `docs/file-format.md` and `docs/compatibility.md` for the local data contract.
 - `docs/privacy-model.md` for export-policy and local data boundaries.
 
+## Use Cases And Workflows
+
+BriefOps helps AI coding threads carry context across issue triage, pull request review, release readiness, incident follow-up, and long-running repository maintenance work.
+
+- [Use Cases](docs/use-cases.md)
+- [Repository Maintenance Workflows](docs/repository-maintenance-workflows.md)
+
 ## Install
 
 From npm:

package/dist/version.d.ts

@@ -1 +1 @@
-export declare const briefopsVersion = "2.1.2";
+export declare const briefopsVersion = "2.1.3";

package/dist/version.js

@@ -1,3 +1,3 @@
 // Keep this version in sync with package.json.
-export const briefopsVersion = "2.1.2";
+export const briefopsVersion = "2.1.3";
 //# sourceMappingURL=version.js.map

package/docs/compatibility.md

@@ -1,4 +1,4 @@
-# BriefOps 2.1.2 Compatibility Policy
+# BriefOps 2.1.3 Compatibility Policy
 
 BriefOps follows semantic versioning for the public CLI and local file formats.
 
@@ -39,7 +39,7 @@ Breaking changes require a new major version. Examples:
 
 New 1.0 workspaces write `version: 1.0.0` in `.briefops/config.yaml`.
 
-BriefOps 2.1.2 keeps the workspace schema at `1.0.0` and can read legacy `0.x` workspace configs on a best-effort compatibility basis. Future unsupported workspace schema major versions fail with an explicit upgrade error instead of silently reading incompatible data.
+BriefOps 2.1.3 keeps the workspace schema at `1.0.0` and can read legacy `0.x` workspace configs on a best-effort compatibility basis. Future unsupported workspace schema major versions fail with an explicit upgrade error instead of silently reading incompatible data.
 
 ## Migration Policy
 

package/docs/evals/briefops-utility-log.md

@@ -0,0 +1,140 @@
+# BriefOps Utility Log
+
+Use this local log to judge whether BriefOps made one real task easier to
+continue. It is intentionally manual. Do not add telemetry, cloud analytics,
+databases, dashboards, or automatic scoring until repeated logs show a concrete
+need.
+
+The goal is to capture evidence for practical utility:
+
+- Did BriefOps reduce re-explanation?
+- Did it preserve prior decisions, lessons, risks, next steps, and commands?
+- Did it produce a better fresh-thread handoff?
+- Did routing avoid unnecessary process while still improving verification?
+
+Use one entry per task or fresh-thread continuation. Keep examples short enough
+that a maintainer can review them in a few minutes.
+
+## Suggested Local Checks
+
+Run only the checks that fit the task:
+
+```bash
+briefops harness route --task "<task>"
+briefops prime --format codex --task "<task>" --max-tokens 800
+briefops obs continuity --worker <worker> --task "<task>" --json
+briefops finish --worker <worker> --task "<task>" --result "<result>"
+briefops continue --worker <worker> --task "<next task>" --pack
+```
+
+For context-size evidence, prefer `briefops obs continuity`. For broader impact
+claims such as token savings, use `docs/impact-report.md` and label anything
+without measured evidence as estimated or unmeasured.
+
+## Scoring
+
+Use simple 0 to 3 scores.
+
+Continuity score:
+
+- 0: Fresh thread still needed full re-explanation.
+- 1: Some useful context survived, but major decisions or risks were missing.
+- 2: Fresh thread could continue with minor clarification.
+- 3: Fresh thread could continue without repeating important context.
+
+Relevance score:
+
+- 0: Mostly unrelated context.
+- 1: Mixed; useful items were buried in unrelated material.
+- 2: Mostly relevant with a little harmless extra context.
+- 3: Compact and directly useful for the task.
+
+Noise score:
+
+- 0: No meaningful noise.
+- 1: Minor extra context.
+- 2: Noticeable bloat or duplicate context.
+- 3: Noise likely slowed the task or risked confusion.
+
+Estimated time saved:
+
+- Use minutes.
+- Write `unmeasured` when there is no credible estimate.
+- Mark estimates as hypotheses unless compared with a similar no-BriefOps run.
+
+## Template
+
+```markdown
+# BriefOps Utility Log
+
+date:
+evaluator:
+project:
+task:
+fresh thread?: yes/no
+BriefOps commands used:
+- 
+
+## Context Evidence
+
+raw candidate context:
+prime context:
+compression ratio:
+route:
+
+## Reuse Evidence
+
+reused decisions:
+- 
+
+reused lessons:
+- 
+
+reused risks:
+- 
+
+reused next steps:
+- 
+
+reused commands:
+- 
+
+## Missing Or Repeated Context
+
+what was still missing:
+- 
+
+repeated explanations:
+- 
+
+repeated rejected approaches:
+- 
+
+## Scores
+
+continuity score:
+relevance score:
+noise score:
+estimated time saved:
+
+## Notes
+
+
+## Follow-Up
+
+promote to memory?: yes/no
+adjust docs or examples?: yes/no
+possible product improvement:
+```
+
+## Review Cadence
+
+After 5 to 10 logs, review them manually and look for repeated patterns:
+
+- Missing decisions suggest finish or memory extraction wording needs work.
+- Missing risks suggest handoff and prime sections need stronger risk selection.
+- High noise suggests memory hygiene, quotas, or examples need tightening.
+- Repeated over-routing suggests route wording or classification needs tuning.
+- Repeated under-routing suggests route risk signals need clearer escalation.
+
+Treat each pattern as a hypothesis until at least two or three logs show it.

package/docs/evals.md

@@ -16,3 +16,12 @@ Prime-context evals should also check that the compact output is materially smal
 ```bash
 npm test -- tests/prime.test.ts
 ```
+
+For real task utility, use the manual utility log:
+
+- [BriefOps Utility Log](evals/briefops-utility-log.md)
+
+The utility log is for local, task-by-task review of re-explanation, preserved
+decisions, preserved risks, handoff quality, routing fit, and verification
+discipline. It complements checklist evals without adding telemetry,
+dashboards, databases, or cloud analytics.

package/docs/repository-maintenance-workflows.md

@@ -0,0 +1,218 @@
+# Repository Maintenance Workflows
+
+BriefOps supports recurring repository maintenance work: issue triage, pull request review, release preparation, incident follow-up, documentation updates, dependency changes, and long-running cleanup.
+
+The workflow pattern is simple:
+
+```text
+prime -> route -> work -> verify -> finish -> continue when needed
+```
+
+Use durable memory for decisions, lessons, incidents, and recurring project constraints. Keep transient notes in work logs or out of memory entirely.
+
+## Workspace Setup
+
+Create a repository-oriented skill, project, and worker once per repository.
+
+```bash
+briefops bootstrap
+
+briefops skill create repo-review \
+  --description "Review repository work for regressions, release risk, privacy boundaries, and missing verification." \
+  --tags "maintenance,review,release"
+
+briefops project create briefops \
+  --description "Local-first CLI for AI coding agent context continuity." \
+  --tags "cli,local-first,ai-agents"
+
+briefops worker create repo-worker \
+  --project briefops \
+  --skills "repo-review" \
+  --style "verify before completion, keep changes scoped, record durable decisions"
+
+briefops worker use repo-worker
+```
+
+Check the workspace before relying on it:
+
+```bash
+briefops doctor --privacy
+briefops doctor --stability
+briefops inspect budget
+```
+
+## Issue Triage
+
+Use this workflow when bugs, support requests, or feature proposals need project context.
+
+```bash
+briefops prime --worker repo-worker --task "Triage new issues." --format codex --max-tokens 800
+briefops harness route --task "Triage new issues."
+```
+
+During triage, record only facts that will help future work:
+
+```bash
+briefops finish \
+  --worker repo-worker \
+  --task "Triage new issues." \
+  --result "Confirmed one reproducible CLI regression and one duplicate support request." \
+  --lesson "Ask for command output and BriefOps version before diagnosing CLI setup failures." \
+  --next-step "Reproduce the regression in a temporary workspace."
+```
+
+Good durable memory candidates:
+
+- supported version boundaries
+- common duplicate reports
+- required reproduction details
+- recurring release or privacy pitfalls
+
+## Pull Request Review
+
+Use the review route when work needs actionable findings, severity ordering, and explicit verification gaps.
+
+```bash
+briefops harness route --task "Review this pull request." --type code-review
+briefops prime --worker repo-worker --task "Review this pull request." --format codex --max-tokens 800
+```
+
+After review, preserve the next useful step:
+
+```bash
+briefops finish \
+  --worker repo-worker \
+  --task "Review this pull request." \
+  --result "Found one blocking issue and one missing test." \
+  --open-risk "The workspace-lock path is not covered by a regression test." \
+  --next-step "Request a targeted regression test before merge."
+```
+
+If review needs to continue in another thread:
+
+```bash
+briefops continue \
+  --worker repo-worker \
+  --task "Finish unresolved PR review checks." \
+  --pack
+```
+
+## Release Preparation
+
+Use the release route when a task needs evidence across build, test, package contents, privacy checks, and release notes.
+
+```bash
+briefops harness route --task "Prepare this release." --type release-preparation
+npm run build
+npm test
+briefops doctor --strict --json
+npm pack --dry-run
+```
+
+If dependency audit or registry checks are part of the release, run them only from an environment where registry metadata disclosure is acceptable:
+
+```bash
+npm audit --audit-level=moderate
+npm view briefops versions --json
+```
+
+Record the release outcome:
+
+```bash
+briefops finish \
+  --worker repo-worker \
+  --task "Prepare this release." \
+  --result "Release verification completed with no blocking failures." \
+  --decision "The package is ready for publish after version confirmation." \
+  --commands "npm run build,npm test,briefops doctor --strict --json,npm pack --dry-run"
+```
+
+Use [Release Checklist](release-checklist.md) for the full local release gate.
+
+## Dependency And Refactor Work
+
+Use routing before broad maintenance changes so the next thread can see the intended depth.
+
+```bash
+briefops harness route --task "Upgrade dependencies and verify compatibility." --type dependency-upgrade
+briefops harness route --task "Refactor memory proposal handling." --type refactor
+```
+
+Before ending a session, record the behavior boundary and verification:
+
+```bash
+briefops finish \
+  --worker repo-worker \
+  --task "Refactor memory proposal handling." \
+  --result "Separated proposal formatting from application without changing public CLI behavior." \
+  --decision "Keep proposal application file-backed and protected by workspace locks." \
+  --commands "npm run build,npm test"
+```
+
+Durable memory should explain the reusable rule, not the mechanics of every edit.
+
+## Documentation Maintenance
+
+Use the documentation route when updating README, guides, or examples.
+
+```bash
+briefops harness route --task "Update documentation for release readiness." --type documentation-task
+briefops prime --worker repo-worker --task "Update documentation for release readiness." --format codex --max-tokens 800
+```
+
+Before finishing, check that commands and links match current behavior:
+
+```bash
+briefops finish \
+  --worker repo-worker \
+  --task "Update documentation for release readiness." \
+  --result "Updated release readiness documentation and linked related guides." \
+  --commands "rg \"doctor --strict|verify:release\" README.md docs"
+```
+
+## Incident Follow-Up
+
+Use the incident route for regressions, broken releases, privacy hazards, or any failure that needs explicit mitigation evidence.
+
+```bash
+briefops harness route --task "Investigate the package release failure." --type production-incident
+briefops prime --worker repo-worker --task "Investigate the package release failure." --format codex --max-tokens 800
+```
+
+Close with an incident, decision, and next step:
+
+```bash
+briefops finish \
+  --worker repo-worker \
+  --task "Investigate the package release failure." \
+  --result "Identified missing dist files in the dry-run package." \
+  --incident "Release candidate omitted generated dist output." \
+  --decision "Run npm pack dry-run after build and before publish." \
+  --next-step "Update release checklist and rerun package verification."
+```
+
+## Sharing Repository Context
+
+Keep `.briefops/` local unless the contents are intentionally curated.
+
+Use `shared-only` for context that may be pasted, attached, or committed:
+
+```bash
+briefops prime --worker repo-worker --task "Review this pull request." --format codex --export-policy shared-only
+briefops pack resume --worker repo-worker --task "Continue review." --export-policy shared-only
+```
+
+Router exports point tools at BriefOps commands and do not copy local memory:
+
+```bash
+briefops export agents-md
+briefops export claude-md
+briefops export cursor-rules
+```
+
+Before publishing or sharing generated context:
+
+```bash
+briefops doctor --privacy
+briefops doctor --strict --json
+```

package/docs/use-cases.md

@@ -0,0 +1,152 @@
+# Use Cases
+
+BriefOps helps developers keep useful AI coding context across fresh threads without turning the repository into a context dump.
+
+Use it when a task depends on prior decisions, recent work, project-specific constraints, or open risks that should survive beyond one chat session.
+
+## Fresh Thread Priming
+
+Use `prime` at the start of a new AI coding thread when the agent needs project context before reading broadly.
+
+```bash
+briefops prime --task "Continue the release readiness review." --format codex --max-tokens 800
+```
+
+This is useful for:
+
+- starting a new thread with a compact project and worker summary
+- avoiding a manual paste of old chat history
+- keeping the first context small enough to inspect
+- applying the same worker style across related tasks
+
+Use a resume pack only when the next thread needs more continuity than `prime` should carry:
+
+```bash
+briefops continue --worker repo-worker --task "Continue the release readiness review." --pack
+```
+
+## Pull Request Review
+
+Use BriefOps when a review has findings, follow-up checks, or risks that may outlive the current thread.
+
+```bash
+briefops harness route --task "Review this pull request." --type code-review
+briefops prime --task "Review this pull request." --format codex --max-tokens 800
+```
+
+After review work finishes, record the result and any unresolved risk:
+
+```bash
+briefops finish \
+  --worker repo-worker \
+  --task "Review this pull request." \
+  --result "Found a blocking regression in the release readiness path." \
+  --open-risk "Strict doctor JSON output still needs targeted verification." \
+  --next-step "Run the strict doctor check and update the review."
+```
+
+This keeps the next review thread focused on unresolved work instead of rediscovering the same findings.
+
+## Release Readiness
+
+Use BriefOps for release work when commands, package contents, privacy checks, and remaining blockers need a durable trail.
+
+```bash
+briefops harness route --task "Prepare this release." --type release-preparation
+npm run build
+npm test
+briefops doctor --strict --json
+npm pack --dry-run
+```
+
+Then close the loop:
+
+```bash
+briefops finish \
+  --worker repo-worker \
+  --task "Prepare this release." \
+  --result "Build, tests, strict doctor, and dry-run package review completed." \
+  --decision "Release package contents are ready for publish." \
+  --commands "npm run build,npm test,briefops doctor --strict --json,npm pack --dry-run"
+```
+
+Run commands that contact external registries only from an environment where that disclosure is acceptable.
+
+## Long-Running Maintenance
+
+Use workers and memory when cleanup, dependency work, or refactors span multiple sessions.
+
+```bash
+briefops skill create repo-review \
+  --description "Review maintenance work for regressions, stale assumptions, and release risk."
+
+briefops project create briefops \
+  --description "Local-first CLI for AI coding agent context continuity."
+
+briefops worker create repo-worker \
+  --project briefops \
+  --skills "repo-review" \
+  --style "small scoped diffs, verify before completion, record durable decisions"
+
+briefops worker use repo-worker
+```
+
+During the work:
+
+```bash
+briefops obs continuity --worker repo-worker --task "Continue dependency cleanup." --json
+briefops prime --worker repo-worker --task "Continue dependency cleanup." --format codex --max-tokens 800
+```
+
+Record only reusable knowledge as durable memory. Use low-importance or no-memory paths for one-off exploration:
+
+```bash
+briefops finish --task "Fix typo" --result "Fixed typo." --importance trivial
+briefops finish --task "Try discarded approach" --result "Discarded." --no-memory-proposal
+```
+
+## Incident Follow-Up
+
+Use the incident route when a regression, outage, or release blocker needs findings, mitigation evidence, and a follow-up trail.
+
+```bash
+briefops harness route --task "Investigate the release regression." --type production-incident
+briefops prime --task "Investigate the release regression." --format codex --max-tokens 800
+```
+
+After mitigation:
+
+```bash
+briefops finish \
+  --worker repo-worker \
+  --task "Investigate the release regression." \
+  --result "Mitigated the failing package check." \
+  --incident "Release dry-run failed because generated files were missing from dist." \
+  --decision "Release verification must include npm pack dry-run before publish." \
+  --next-step "Add the package check to the release checklist."
+```
+
+## Privacy-Safe Sharing
+
+Use `shared-only` when generated context may leave the local workspace.
+
+```bash
+briefops prime --task "Review this pull request." --format codex --export-policy shared-only
+briefops pack resume --worker repo-worker --task "Continue the review." --export-policy shared-only
+```
+
+`shared-only` includes only memory marked `visibility: shared` and `exportable: true`. It omits private memory, raw work logs, open risks, local next steps, private worker history, incidents, and private metadata counts.
+
+Before publishing a repository or sharing generated context, run:
+
+```bash
+briefops doctor --privacy
+briefops doctor --stability
+briefops doctor --strict --json
+```
+
+Router exports are safe to commit when reviewed because they point tools at BriefOps commands instead of copying `.briefops/` memory:
+
+```bash
+briefops export all
+```

package/examples/evals/briefops-harness-continuity.md

@@ -0,0 +1,66 @@
+# BriefOps Utility Log: Harness Continuity
+
+date: 2026-07-05
+evaluator: maintainer example
+project: briefops
+task: Continue Master Harness product review in a fresh Codex thread.
+fresh thread?: yes
+BriefOps commands used:
+- `briefops harness route --task "Review BriefOps 2.1.x product improvement opportunities."`
+- `briefops prime --format codex --task "Review BriefOps 2.1.x product improvement opportunities." --max-tokens 800`
+- `briefops obs continuity --worker briefops-maintainer --task "Review BriefOps 2.1.x product improvement opportunities." --json`
+
+## Context Evidence
+
+raw candidate context: observed through `obs continuity`
+prime context: compact Codex-format context under the requested budget
+compression ratio: copy from `obs continuity` when running the example
+route: code-review or exploratory-research, depending on exact task wording
+
+## Reuse Evidence
+
+reused decisions:
+- Missing `briefops` on PATH should be `Status: setup-required`.
+- BriefOps should preserve local-first memory and avoid becoming an agent runtime.
+
+reused lessons:
+- Keep plugin cache and local plugin path synchronized during release work.
+
+reused risks:
+- npm publish may remain blocked by npm authentication.
+
+reused next steps:
+- Verify release-readiness behavior before publishing.
+
+reused commands:
+- `briefops prime --format codex --task "<task>" --max-tokens 800`
+- `briefops continue --worker briefops-maintainer --task "<task>" --pack`
+
+## Missing Or Repeated Context
+
+what was still missing:
+- Whether the previous route classification was correct for a product-review task.
+
+repeated explanations:
+- The reviewer still had to restate the product boundary from the user prompt.
+
+repeated rejected approaches:
+- MCP server, dashboard, database, vector search, and cloud sync remained out of scope.
+
+## Scores
+
+continuity score: 2
+relevance score: 3
+noise score: 1
+estimated time saved: 10 minutes, hypothesis
+
+## Notes
+
+Prime carried release and setup context well. The product boundary still came
+from the task prompt, which is appropriate because it is user-specified scope.
+
+## Follow-Up
+
+promote to memory?: no
+adjust docs or examples?: yes
+possible product improvement: Add a lightweight utility log so this judgment is repeatable.

package/examples/evals/pr-review.md

@@ -0,0 +1,66 @@
+# BriefOps Utility Log: Pull Request Review
+
+date: 2026-07-05
+evaluator: maintainer example
+project: briefops
+task: Review a pull request for regressions, privacy leaks, and missing tests.
+fresh thread?: yes
+BriefOps commands used:
+- `briefops harness route --task "Review this pull request." --type code-review`
+- `briefops prime --format codex --task "Review this pull request." --max-tokens 800`
+- `briefops finish --worker briefops-maintainer --task "Review this pull request." --result "<result>" --open-risk "<risk>" --next-step "<next step>"`
+- `briefops continue --worker briefops-maintainer --task "Finish unresolved PR review checks." --pack`
+
+## Context Evidence
+
+raw candidate context: observed through `obs continuity`
+prime context: compact review context plus route contract
+compression ratio: copy from `obs continuity`
+route: code-review
+
+## Reuse Evidence
+
+reused decisions:
+- Shared-only exports must omit private memory, local project file details, raw logs, open risks, and private metadata counts.
+
+reused lessons:
+- Review outputs should lead with actionable findings and explicit verification gaps.
+
+reused risks:
+- A change touching shared output paths can leak private continuity data if not checked.
+
+reused next steps:
+- Run targeted tests for shared-only output and output overwrite protection.
+
+reused commands:
+- `npm test -- tests/safety.test.ts`
+- `npm test -- tests/output-safety.test.ts`
+
+## Missing Or Repeated Context
+
+what was still missing:
+- Exact changed files in the pull request; BriefOps does not inspect the diff for the reviewer.
+
+repeated explanations:
+- The user still needed to provide the PR or diff target.
+
+repeated rejected approaches:
+- Treating context compression as proof that the review was correct.
+
+## Scores
+
+continuity score: 2
+relevance score: 2
+noise score: 1
+estimated time saved: 8 minutes, hypothesis
+
+## Notes
+
+BriefOps helps preserve review style, known risks, and follow-up checks. It does
+not replace source inspection or diff review.
+
+## Follow-Up
+
+promote to memory?: only for durable findings or repeated failure patterns
+adjust docs or examples?: yes, if reviewers repeatedly miss the expected final response contract
+possible product improvement: Add more example logs before changing routing logic.

package/examples/evals/release-readiness.md

@@ -0,0 +1,71 @@
+# BriefOps Utility Log: Release Readiness
+
+date: 2026-07-05
+evaluator: maintainer example
+project: briefops
+task: Prepare a patch release and verify local release readiness.
+fresh thread?: no
+BriefOps commands used:
+- `briefops harness route --task "Prepare this release." --type release-preparation`
+- `briefops doctor --strict --json`
+- `briefops obs continuity --worker briefops-maintainer --task "Prepare this release." --json`
+- `briefops finish --worker briefops-maintainer --task "Prepare this release." --result "<result>" --commands "npm run build,npm test,briefops doctor --strict --json,npm pack --dry-run"`
+
+## Context Evidence
+
+raw candidate context: observed through `obs continuity`
+prime context: not used if continuing in the same terminal session
+compression ratio: copy from `obs continuity` if prime was used
+route: release-preparation
+
+## Reuse Evidence
+
+reused decisions:
+- Warnings from strict doctor should keep `releaseReady` false.
+- Generated harness files must be routers, not memory dumps.
+
+reused lessons:
+- Run package dry-run after build and before publish.
+
+reused risks:
+- npm registry commands disclose dependency or package metadata.
+- npm authentication can block publish even when local release checks pass.
+
+reused next steps:
+- Authenticate npm before publishing.
+- Review package contents before release.
+
+reused commands:
+- `npm run build`
+- `npm test`
+- `briefops doctor --strict --json`
+- `npm pack --dry-run`
+
+## Missing Or Repeated Context
+
+what was still missing:
+- Actual npm authentication state, because it must be checked in the release environment.
+
+repeated explanations:
+- None if the release checklist and prior memory were available.
+
+repeated rejected approaches:
+- Skipping strict doctor because build and tests passed.
+
+## Scores
+
+continuity score: 3
+relevance score: 3
+noise score: 0
+estimated time saved: 15 minutes, hypothesis
+
+## Notes
+
+This is a strong BriefOps use case because release work depends on remembered
+commands, blockers, and verification discipline.
+
+## Follow-Up
+
+promote to memory?: yes, if a new blocker or release rule was discovered
+adjust docs or examples?: no
+possible product improvement: Keep release-readiness examples tied to strict doctor and pack dry-run evidence.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "briefops",
-  "version": "2.1.2",
+  "version": "2.1.3",
   "description": "Local-first CLI for AI coding agents with persistent memory, handoffs, and token-aware context.",
   "type": "module",
   "bin": {

package/plugins/briefops-codex/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "briefops",
-  "version": "2.1.2",
+  "version": "2.1.3",
   "description": "Local-first, token-aware persistent work history for Codex workflows.",
   "author": {
     "name": "BriefOps contributors",