[AksharP5]

What

hyperframes add <tag> now reports an incomplete installation as a failure. Scripts and agents receive exit code 1 and ok: false when any block fails; JSON includes each failed block's name and error. Successful installations remain available.

Why

The tag loop catches each install error and then reports unconditional success. In JSON mode, it also drops every failure reason.

The same real source CLI process with fixture HTTP responses:

Download results	Before	After
All fail with HTTP 404	Exit 0; ok: true; no files; no errors	Exit 1; ok: false; named HTTP 404 error
One fails, one succeeds	Exit 0; ok: true	Exit 1; ok: false; successful HTML preserved
All succeed	Exit 0; ok: true	Exit 0; ok: true; errors: []

The issue includes a self-contained reproduction. Only HTTP responses are fixtures; dispatch, resolution, installation, filesystem writes and process exit handling use the real implementation.

Related work

Fixes #6084.

#4432 preserves warnings from successful installs. Open #5256 refreshes item manifests during discovery; neither handles failed file installation.

How

Collect per-item errors, derive JSON status from the collection and use the existing command-failure boundary after the batch finishes. The human summary marks incomplete installs as an error. Document the exit status and JSON fields.

Test plan

• Command regressions cover total failure, partial failure, success and non-JSON failure.
• Failure regressions fail on the base implementation.
• Add, installer and resolver suites: 72 passed, including success/failure summary markers without color.
• Actual source CLI process before/after inspected, including exit status and installed files.
• Changed TypeScript passes oxlint and oxfmt; diff whitespace check passes.
• CLI documentation updated; comment/process-ownership checks run before push.

Validated on main 10c724bf5, Linux x86_64, Node 26.11.1, Bun 1.4.1 (repository pins 1.4.4), and Citty 0.2.2. CLI TypeScript checking reports a missing installed @aws-sdk/s3-request-presigner dependency through AWS Lambda source and no changed-file type errors. Full workspace checks have the same dependency limitation; mint is absent, so full docs validation was not run.

[mintlify]

Preview approval required

This pull request comes from a fork, so Mintlify won't build a preview until someone with write access approves commit eb6fd15.

Approve preview

[miguel-heygen]

Thanks for this, and for the reproduction in the issue. The exit code and the JSON errors list are right, the tests go through the real command path, and no other caller has the same swallow then succeed loop.

One thing to fix before this lands: the human summary at packages/cli/src/commands/add.ts:618 lost its status glyph. Colors are identity when stdout is not a TTY, so hyperframes add sometag > add.log now writes a bare Installed 0/2 blocks with no marker, where it used to write a checkmark on success. Keeping a glyph restores it: console.log(${errors.length > 0 ? c.error("✗") : c.success("✓")} ${summary}). The non JSON test only asserts the per item "HTTP 404" line, so tightening it to the summary would pin this too.

[AksharP5]

@miguel-heygen Fixed in eb6fd15. Tag summaries retain the success/failure marker when stdout has no color. The tests now assert the final summary for both outcomes; both new assertions failed before the fix, and all 72 add/installer/resolver tests pass. Lint, formatting, comment checks and pre-commit checks pass. The full local build and CLI typecheck remain limited by missing preinstalled inspector/AWS dependencies, as noted in the description. Ready for re-review while CI runs.

[miguel-heygen]

Thanks for turning this around so quickly. The summary keeps its marker now in both outcomes, and tightening the non JSON assertion to the whole summary line is what pins it, so a future refactor that drops the glyph will fail the test rather than quietly ship.

I checked the rest again at this head: the single item path already failed correctly, nothing else parses the tag JSON, and errors is additive so the success shape stays compatible. CI is green across the producer, docs and CLI shim jobs.

Approving.

[jrusso1020]

Approving. On main, the add <tag> loop in packages/cli/src/commands/add.ts catches each install error, prints it, and then reports ok: true with exit 0, so a script or agent cannot tell that nothing was installed. With --json the failure reason is dropped entirely.

The fix collects per-item errors, sets ok from them, adds an errors array, and ends with the existing failCommand(). That matches how the single-item and empty-tag paths a few lines above already fail, so the exit contract is now consistent across the command. Successful installs are still written. Files kept because the project edited them are skipped inside the installer without throwing, so re-running a tag install does not start failing.

I ran the new tests against main without the fix: all five scenarios fail. With the fix, the file passes 35/35. Miguel's earlier request (keep the success/failure marker when stdout has no color) is addressed at this head.

Need: yes, partial and total tag-install failures exit 0 today · Size: ok · Reuse: uses the existing failCommand boundary · Simpler: already minimal

— Rames