release: v0.8.0

[samtay32]

What changed

• synchronize package, lockfile, plugin, and CLI fallback metadata at 0.8.0;
• document provider-neutral work contracts, scoped Linear integration, bounded
  campaigns, evidence reports, read-only telemetry adapters, and Qodo receipts
  in the changelog.

Why

All product work merged after v0.7.2 must be distributed to npm users. These
capabilities are additive and backwards-compatible, so they require a minor
SemVer release.

Validation

• npm run release:check — 147 tests, behavioral contracts, package dry-run,
  and packed-install smoke;
• npx --yes node@22 --test — 147 tests;
• markdownlint-cli2 — 59 tracked Markdown files;
• synchronized 0.8.0 identity across all five version locations;
• npm ultimate-agent-stack@0.8.0 and Git tag v0.8.0 confirmed unused.

Release authority

This PR prepares source only. npm publication remains protected by the GitHub
npm environment, trusted publishing, npm staged publishing, provenance, and
human approval/2FA.

Live Codex behavioral evidence for the changed surface will be attached as a
PR comment. Other supported harnesses are not claimed as tested.

Summary by CodeRabbit

• New Features

  • Added provider-neutral repository contract normalization.
  • Added guided Linear health checks and optional issue/evidence comment creation.
  • Added campaign work-item selection with bounded iterations.
  • Added deterministic evidence reports with JSON coverage and Mermaid maps.
  • Added optional read-only PostHog, Sentry, and New Relic health checks.

• Security

  • Strengthened Linear write authorization and confirmation requirements.
  • Improved validation for telemetry scope and evidence report paths.

• Documentation

  • Documented onboarding updates, provider setup guidance, and provider-neutral boundaries.

• Release

  • Updated the release version to 0.8.0.

[samtay32]

/review

[coderabbitai]

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 5cac5c1a-84eb-4a08-9e90-4e5faad0e112

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

📝 Walkthrough

Walkthrough

The release version was bumped from 0.7.2 to 0.8.0 across package metadata and the CLI fallback. A dated changelog section documents the release additions, behavior changes, and security requirements.

Changes

Release 0.8.0

Layer / File(s)	Summary
Synchronize release version metadata .codex-plugin/plugin.json, package.json, bin/ultimate-agent-stack.mjs	Package metadata and the CLI fallback now report version 0.8.0.
Document the 0.8.0 release CHANGELOG.md	Added the dated 0.8.0 release notes covering additions, behavior changes, and security requirements.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Possibly related PRs

• samtay32/ultimate-agent-stack#5: Updates the same release metadata and changelog locations.
• samtay32/ultimate-agent-stack#12: Synchronizes the same version fields and release documentation.
• samtay32/ultimate-agent-stack#22: Performs a coordinated version bump across the same files.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies the v0.8.0 release prep reflected by the version bumps and changelog update.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch codex/release-v080

---

_{Comment @coderabbitai help to get the list of available commands.}

[qodo-code-review]

PR Summary by Qodo

Release v0.8.0: bump versions and publish changelog

⚙️ Configuration changes 📝 Documentation 🕐 10-20 Minutes

AI Description

• Bump all release/version identifiers from 0.7.2 to 0.8.0 across distribution metadata.
• Update CLI fallback package metadata so packaged installs report the correct version.
• Publish the v0.8.0 changelog covering new work/evidence/telemetry capabilities and security
 constraints.

Diagram

graph TD
  R(["Release prep"]) --> V["Version: 0.8.0"] --> PJ["package.json"] --> PL["package-lock.json"] --> CP[".codex-plugin/plugin.json"] --> CLI["bin/ultimate-agent-stack.mjs"] --> CL["CHANGELOG.md"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Single source-of-truth version + generation script

• ➕ Eliminates manual drift across package.json, lockfile, plugin.json, and CLI fallback defaults
• ➕ Makes release prep repeatable and easier to validate in CI
• ➖ Requires introducing/maintaining a small release script and updating contributor workflow

2. Adopt standard release tooling (e.g., Changesets or release-please)

• ➕ Automates version bumps, changelog generation, and tagging in a consistent workflow
• ➕ Reduces human error for future releases
• ➖ Adds tooling/config overhead and may not fit the repo’s existing release authority controls

Recommendation: The current approach is appropriate for a straightforward manual release cut. If this repo will ship frequent releases, consider a single source-of-truth version (or standard release tooling) to prevent version drift across the multiple metadata locations updated here.

Files changed (5) +50 / -5

Documentation (1) +45 / -0

CHANGELOG.mdAdd v0.8.0 release notes +45/-0

Add v0.8.0 release notes

• Adds a dated 0.8.0 section with Added/Changed/Security notes describing new provider-neutral work contracts, Linear integration, campaigns, evidence reports, and telemetry adapters.

CHANGELOG.md

Other (4) +5 / -5

plugin.jsonBump Codex plugin version to 0.8.0 +1/-1

Bump Codex plugin version to 0.8.0

• Updates the plugin manifest version from 0.7.2 to 0.8.0 to keep plugin metadata aligned with the npm release.

.codex-plugin/plugin.json

ultimate-agent-stack.mjsUpdate CLI fallback version to 0.8.0 +1/-1

Update CLI fallback version to 0.8.0

• Updates the hardcoded fallback package metadata used when package.json cannot be read so the CLI reports version 0.8.0 in that scenario.

bin/ultimate-agent-stack.mjs

package-lock.jsonSynchronize lockfile version to 0.8.0 +2/-2

Synchronize lockfile version to 0.8.0

• Bumps the lockfile package version fields from 0.7.2 to 0.8.0 to match the release version across install artifacts.

package-lock.json

package.jsonBump npm package version to 0.8.0 +1/-1

Bump npm package version to 0.8.0

• Updates the package.json version from 0.7.2 to 0.8.0 for the minor SemVer release.

package.json

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (1)

Context used

✅ Compliance rules (platform): 79 rules

✅ Skills: 4 invoked

  verify-change

  maintain-agent-stack

  build-vertical-slice

  secure-launch

1. Nonterminal Qodo reviews accepted ✓ Resolved 🐞 Bug ⛨ Security ⭐ New

Description

The new Qodo “terminal clean” receipt path accepts any bot comment containing phrases like “no
issues found” / “no material issues” as long as it doesn’t match the narrow processing regex, so a
provisional update such as “No issues found yet” (with the exact-head marker) can incorrectly
satisfy the review receipt gate.

Code

scripts/review-receipt.mjs[R15-18]

+const QODO_CLEAN_COMPLETION_PATTERNS = [
+  /(?:<h[1-6]\b[^>]*>|^\s*#{1,6}\s+)\s*(?:great[\s,:!.\u2013\u2014-]*)?no\s+(?:material\s+)?issues?\s+(?:were\s+)?found\b/im,
+  /\b(?:found\s+no|no)\s+material\s+issues?(?:\s+(?:that\s+)?(?:require|requiring)\s+review)?\b/i,
+];

Relevance

●●● Strong

Team consistently hardens review-receipt gates to fail-closed; likely to tighten regex and add
bypass test.

PR-#31
PR-#9

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The completion detector relies on broad “clean” regexes and only filters out a small set of
processing phrases, so provisional wording like “No issues found yet” matches the clean patterns and
can pass when it omits those processing keywords. The current tests only reject the “yet” wording
when it also includes “Qodo is still working…”, leaving the bypass untested.

scripts/review-receipt.mjs[13-18]
scripts/review-receipt.mjs[58-63]
test/review-receipt.test.mjs[79-88]
test/review-receipt.test.mjs[210-242]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Qodo terminal-clean completion detection currently matches broad “no issues found” / “no material issues” phrases without excluding provisional qualifiers (e.g., “yet”, “so far”). If a Qodo bot comment contains `Code Review by Qodo`, includes the exact head commit marker, and says something like “No issues found yet” without the specific “processing/working” wording, it can be misclassified as a completed review and satisfy the receipt gate.

## Issue Context
- `qodoCompletionMatches()` now has a `currentCleanCompletion` path that:
 - requires the Qodo title,
 - requires absence of `QODO_PROCESSING_PATTERN`,
 - requires any match from `QODO_CLEAN_COMPLETION_PATTERNS`, and
 - requires an exact-head commit marker.
- The clean-completion patterns currently match strings like `No issues found yet` because the regex stops at the word boundary after `found`.

## Fix Focus Areas
- scripts/review-receipt.mjs[13-18]
- scripts/review-receipt.mjs[58-63]
- test/review-receipt.test.mjs[79-89]
- test/review-receipt.test.mjs[210-243]

## Suggested fix approach
1. Add an explicit guard for provisional qualifiers (e.g., `\b(?:yet|so\s+far)\b/i`) and require it to *not* match for `currentCleanCompletion`.
  - Alternatively (or additionally), tighten the existing clean patterns with a negative lookahead so `found` is not immediately followed by `yet/so far`.
2. Add a regression test in `test("accepts bounded Qodo terminal-clean wording and heading variants", ...)` verifying that a clean-looking body such as `"### No issues found yet\nAwaiting more checks."` (with the exact-head marker and without any “processing/working” phrase) is rejected.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Implicit activation enabled for mutating skills 📜 Skill insight ⛨ Security

Description

Multiple entry skills now set allow_implicit_invocation: true, which loosens the
explicit-intent/authority boundary and can allow side-effecting workflows (setup, delivery,
maintenance) to run without an explicit user invocation. This weakens authority boundaries contrary
to the security-boundary requirement.

Code

skills/run-autonomous-delivery/agents/openai.yaml[R5-6]

policy:
-  allow_implicit_invocation: false
+  allow_implicit_invocation: true

Relevance

●● Moderate

Implicit invocation for entry skills seems intentional, but security-boundary expectations are
unclear; no close precedent on this flag.

PR-#19

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 2395879 prohibits weakening authority boundaries. The PR explicitly enables
implicit invocation for multiple entry skills (including mutating ones like
setup/delivery/maintenance), and adds a test asserting these adapters must permit implicit
activation, demonstrating an intentional boundary relaxation.

skills/run-autonomous-delivery/agents/openai.yaml[5-6]
skills/setup-autonomous-project/agents/openai.yaml[5-6]
skills/maintain-agent-stack/agents/openai.yaml[5-6]
skills/use-project-telemetry/agents/openai.yaml[5-6]
test/maintenance.test.mjs[91-101]
test/maintenance.test.mjs[379-383]
Skill: maintain-agent-stack

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Several side-effecting entry skills now allow implicit invocation (`allow_implicit_invocation: true`). This relaxes the intent/authority boundary and risks unexpected execution of workflows that can modify repos or interact with external systems.

## Issue Context
These skills include delivery/setup/maintenance surfaces that are explicitly described as requiring explicit use (e.g., `run-autonomous-delivery`). Enabling implicit invocation contradicts that boundary and constitutes a security-boundary loosening.

## Fix Focus Areas
- skills/run-autonomous-delivery/agents/openai.yaml[5-6]
- skills/setup-autonomous-project/agents/openai.yaml[5-6]
- skills/maintain-agent-stack/agents/openai.yaml[5-6]
- skills/use-project-telemetry/agents/openai.yaml[5-6]
- test/maintenance.test.mjs[91-101]
- test/maintenance.test.mjs[379-383]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Brittle Qodo clean matcher ✓ Resolved 🐞 Bug ☼ Reliability

Description

The new Qodo terminal-clean completion detection hard-codes a specific HTML heading and exact
sentence, so equivalent “clean” Qodo reviews with minor formatting/wording differences can be
rejected and block review-receipt. The accompanying tests only cover this single exact body shape,
increasing the risk of false-negative receipt failures if Qodo output formatting changes.

Code

scripts/review-receipt.mjs[R13-14]

+const QODO_CLEAN_COMPLETION_PATTERN =
+  /<h3>\s*Great,\s*no issues found!\s*<\/h3>[\s\S]*\bQodo reviewed your code and found no material issues that require review\b/i;

Relevance

●●● Strong

Team previously accepted broadening Qodo receipt matchers to avoid fail-closed formatting changes;
likely will relax this regex/tests.

PR-#31

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The terminal-clean path is implemented by requiring a very specific HTML <h3> header and an exact
follow-up sentence, and then the tests only exercise that exact string. Meanwhile, the documentation
describes acceptance of Qodo’s “terminal-clean Code Review by Qodo body” in general terms (not as
a single immutable HTML template), so this strictness creates a realistic false-negative risk for
the protected receipt check.

scripts/review-receipt.mjs[12-14]
scripts/review-receipt.mjs[42-58]
docs/GITHUB_LOOP.md[75-80]
test/review-receipt.test.mjs[66-77]
test/review-receipt.test.mjs[155-197]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `QODO_CLEAN_COMPLETION_PATTERN` used for Qodo’s terminal-clean receipt validation is overly strict (exact `<h3>` HTML + fixed sentence), which can fail closed on minor provider formatting/wording changes and block the protected `review-receipt` gate.

## Issue Context
- The evaluator now accepts Qodo’s “terminal-clean `Code Review by Qodo` body” path, but the implementation encodes one exact HTML/string shape.
- Tests only validate that one exact fixture is accepted, so acceptable variants are not protected.

## Fix Focus Areas
- scripts/review-receipt.mjs[13-14]
- scripts/review-receipt.mjs[54-58]
- test/review-receipt.test.mjs[66-77]
- test/review-receipt.test.mjs[155-198]

## What to change
1. Make terminal-clean detection more tolerant while still distinguishing it from processing/summary comments:
  - Allow Markdown headings (e.g., `### Great, no issues found!`) in addition to `<h3>...`.
  - Avoid requiring the exact full sentence; instead match a stable subset (e.g., `no material issues` / `no issues found`) with bounded whitespace/punctuation.
2. Add tests that:
  - Accept a terminal-clean review with Markdown headings.
  - Accept a terminal-clean review with small wording/punctuation differences (but still clearly “clean”).
  - Continue rejecting PR summaries and non-terminal “agents are working…” bodies.

## Acceptance criteria
- `evaluateReviewReceipt({ provider: "qodo" })` still rejects summary/processing comments.
- The terminal-clean path remains bound to `qodoExactHeadMatches(...)`.
- New tests demonstrate acceptance for at least one non-HTML variant without weakening exact-head enforcement.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

Previous review results

Review updated until commit 571c140

Results up to commit c3a3388 ⚖️ Balanced

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (1)

1. Implicit activation enabled for mutating skills 📜 Skill insight ⛨ Security

Description

Multiple entry skills now set allow_implicit_invocation: true, which loosens the
explicit-intent/authority boundary and can allow side-effecting workflows (setup, delivery,
maintenance) to run without an explicit user invocation. This weakens authority boundaries contrary
to the security-boundary requirement.

Code

skills/run-autonomous-delivery/agents/openai.yaml[R5-6]

policy:
-  allow_implicit_invocation: false
+  allow_implicit_invocation: true

Relevance

●● Moderate

Implicit invocation for entry skills seems intentional, but security-boundary expectations are
unclear; no close precedent on this flag.

PR-#19

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 2395879 prohibits weakening authority boundaries. The PR explicitly enables
implicit invocation for multiple entry skills (including mutating ones like
setup/delivery/maintenance), and adds a test asserting these adapters must permit implicit
activation, demonstrating an intentional boundary relaxation.

skills/run-autonomous-delivery/agents/openai.yaml[5-6]
skills/setup-autonomous-project/agents/openai.yaml[5-6]
skills/maintain-agent-stack/agents/openai.yaml[5-6]
skills/use-project-telemetry/agents/openai.yaml[5-6]
test/maintenance.test.mjs[91-101]
test/maintenance.test.mjs[379-383]
Skill: maintain-agent-stack

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Several side-effecting entry skills now allow implicit invocation (`allow_implicit_invocation: true`). This relaxes the intent/authority boundary and risks unexpected execution of workflows that can modify repos or interact with external systems.

## Issue Context
These skills include delivery/setup/maintenance surfaces that are explicitly described as requiring explicit use (e.g., `run-autonomous-delivery`). Enabling implicit invocation contradicts that boundary and constitutes a security-boundary loosening.

## Fix Focus Areas
- skills/run-autonomous-delivery/agents/openai.yaml[5-6]
- skills/setup-autonomous-project/agents/openai.yaml[5-6]
- skills/maintain-agent-stack/agents/openai.yaml[5-6]
- skills/use-project-telemetry/agents/openai.yaml[5-6]
- test/maintenance.test.mjs[91-101]
- test/maintenance.test.mjs[379-383]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Brittle Qodo clean matcher ✓ Resolved 🐞 Bug ☼ Reliability

Description

The new Qodo terminal-clean completion detection hard-codes a specific HTML heading and exact
sentence, so equivalent “clean” Qodo reviews with minor formatting/wording differences can be
rejected and block review-receipt. The accompanying tests only cover this single exact body shape,
increasing the risk of false-negative receipt failures if Qodo output formatting changes.

Code

scripts/review-receipt.mjs[R13-14]

+const QODO_CLEAN_COMPLETION_PATTERN =
+  /<h3>\s*Great,\s*no issues found!\s*<\/h3>[\s\S]*\bQodo reviewed your code and found no material issues that require review\b/i;

Relevance

●●● Strong

Team previously accepted broadening Qodo receipt matchers to avoid fail-closed formatting changes;
likely will relax this regex/tests.

PR-#31

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The terminal-clean path is implemented by requiring a very specific HTML <h3> header and an exact
follow-up sentence, and then the tests only exercise that exact string. Meanwhile, the documentation
describes acceptance of Qodo’s “terminal-clean Code Review by Qodo body” in general terms (not as
a single immutable HTML template), so this strictness creates a realistic false-negative risk for
the protected receipt check.

scripts/review-receipt.mjs[12-14]
scripts/review-receipt.mjs[42-58]
docs/GITHUB_LOOP.md[75-80]
test/review-receipt.test.mjs[66-77]
test/review-receipt.test.mjs[155-197]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `QODO_CLEAN_COMPLETION_PATTERN` used for Qodo’s terminal-clean receipt validation is overly strict (exact `<h3>` HTML + fixed sentence), which can fail closed on minor provider formatting/wording changes and block the protected `review-receipt` gate.

## Issue Context
- The evaluator now accepts Qodo’s “terminal-clean `Code Review by Qodo` body” path, but the implementation encodes one exact HTML/string shape.
- Tests only validate that one exact fixture is accepted, so acceptable variants are not protected.

## Fix Focus Areas
- scripts/review-receipt.mjs[13-14]
- scripts/review-receipt.mjs[54-58]
- test/review-receipt.test.mjs[66-77]
- test/review-receipt.test.mjs[155-198]

## What to change
1. Make terminal-clean detection more tolerant while still distinguishing it from processing/summary comments:
  - Allow Markdown headings (e.g., `### Great, no issues found!`) in addition to `<h3>...`.
  - Avoid requiring the exact full sentence; instead match a stable subset (e.g., `no material issues` / `no issues found`) with bounded whitespace/punctuation.
2. Add tests that:
  - Accept a terminal-clean review with Markdown headings.
  - Accept a terminal-clean review with small wording/punctuation differences (but still clearly “clean”).
  - Continue rejecting PR summaries and non-terminal “agents are working…” bodies.

## Acceptance criteria
- `evaluateReviewReceipt({ provider: "qodo" })` still rejects summary/processing comments.
- The terminal-clean path remains bound to `qodoExactHeadMatches(...)`.
- New tests demonstrate acceptance for at least one non-HTML variant without weakening exact-head enforcement.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[samtay32]

/improve

[qodo-code-review]

Code review by qodo was updated up to the latest commit c3a3388

[samtay32]

/improve

[qodo-code-review]

Code review by qodo was updated up to the latest commit 155c4de

[samtay32]

/improve

[qodo-code-review]

Code review by qodo was updated up to the latest commit 571c140

[samtay32]

Behavioral release evidence for v0.8.0

• Evaluator: npm run eval:behavior -- --input /tmp/uas-live-eval-v080-record.json
• Result: 14/14 scenarios passed against behavior surface sha256:e31ce7e5debf0c8a2c9033e7dffb18f08ed4bafa36666467e3d7c7dd1e34b94e
• Harness: Codex CLI 0.145.0, model gpt-5.6-sol
• Categories: direct, indirect, incomplete, negative, edge, authority, continuity, and existing-project
• Persistent traces: 019fae94-9976-7f03-aa05-b5322f882318, 019fae94-99d9-7300-9d77-2e34c485dc85, 019fae95-ad6c-7b61-ad74-751384d7b27a, 019fae95-ad74-79f1-b70b-56cacb924c8c, 019fae95-ad69-7241-9986-dbfa6dfe6f32, 019fae95-ad6b-7a81-a5b9-7d05860d093a, 019fae94-9946-7ae2-b43f-0e7fe37b76a3, 019fae94-99c6-7471-be49-b8cc0e051a88, 019fae94-998e-7371-8c40-96d08a0cc811, 019fae95-117e-7bb0-87f2-f33d6aeba0ed, 019fae95-117e-7fe1-a09c-7babc0eb905e, 019fae95-1185-7bd2-9b9d-cdbc28b1c645, 019fae95-117e-7733-9905-934860253021, 019fae95-1185-7ef0-b24a-470bfdc6bec1

Observed boundaries included safe refusal of gate bypass, unbounded campaigns, release without authority, and a second coordinator. Linear used an intentionally invalid evaluation credential, so it exercised provider verification and a failed-attempt receipt without creating a remote issue. Telemetry credentials were unavailable, so it exercised the bounded repository fallback. Claude, Gemini, Cursor, Grok, and OpenCode were not tested in this live run; deterministic adapter contracts and CI remain green for the shipped surfaces.