code-foundry 1.11.0 → 1.13.0

package/.github/workflows/validation_self-ci.yml

@@ -7,6 +7,7 @@ on:
     branches: [main, staging]
     types:
       - ready_for_review
+      - synchronize
 
 # Default every caller job to no repository permissions. Individual jobs grant
 # only the scopes their own validation path consumes.
@@ -20,9 +21,10 @@ concurrency:
 jobs:
   mode:
     name: Mode
-    # The mode classifier is only needed for pull requests. Main pushes use
-    # the dedicated default-branch CodeQL lane below.
-    if: vars.CI_BILLING_PAUSED != 'true' && github.event_name == 'pull_request'
+    # The mode classifier is only needed for ready pull requests. Main pushes
+    # use the dedicated default-branch CodeQL lane below; draft updates do not
+    # allocate a validation runner.
+    if: vars.CI_BILLING_PAUSED != 'true' && github.event_name == 'pull_request' && github.event.pull_request.draft == false
     runs-on: ubuntu-slim
     timeout-minutes: 10
     permissions:
@@ -62,7 +64,7 @@ jobs:
   validation:
     name: Validation
     needs: mode
-    if: vars.CI_BILLING_PAUSED != 'true' && github.event_name == 'pull_request'
+    if: vars.CI_BILLING_PAUSED != 'true' && github.event_name == 'pull_request' && github.event.pull_request.draft == false
     # Reusable workflows can only maintain or reduce the caller job's scopes.
     # The audit tier needs security-events: write for CodeQL uploads.
     permissions:

package/AGENTS.md

@@ -103,13 +103,14 @@ This repository uses the `direct` workflow. Topic pull requests target `main`.
 - Open every ordinary pull request as a draft. Use `gh pr create --draft` or
   set `draft: true` in the GitHub API; never create a ready ordinary pull
   request as a shortcut.
-- Keep ordinary pull requests in draft while making commits. The generated
-  Draft Guard resets a ready ordinary pull request to draft on creation,
-  reopening, or a new commit, and runner-heavy validation starts only after an
+- Keep ordinary pull requests in draft while preparing them. The generated
+  Draft Guard converts ready ordinary pull requests to draft when they are
+  opened or reopened, and runner-heavy validation starts only after an
   explicit `ready_for_review` transition.
 - Run local validation and finish review preparation before marking an ordinary
-  pull request ready. After any later commit, mark it ready again only after
-  the current head is ready for review.
+  pull request ready. Ready pull requests stay ready when new commits arrive,
+  and validation reruns for the current head; draft updates allocate no
+  validation runner until the pull request is ready.
 - This contract is mandatory for every agent scope. Nested `AGENTS.md` files
   may add stricter rules but must not weaken or replace it.
 - Release Please version pull requests are managed by the Code Foundry release

package/CHANGELOG.md

@@ -1,5 +1,19 @@
 # Changelog
 
+## [1.13.0](https://github.com/0xPlayerOne/code-foundry/compare/v1.12.0...v1.13.0) (2026-09-09)
+
+
+### Features
+
+* **fleet:** add declared inventory and resumable canary rollouts ([#536](https://github.com/0xPlayerOne/code-foundry/issues/536)) ([6aa86d4](https://github.com/0xPlayerOne/code-foundry/commit/6aa86d4cd85cdbd4041c70d8c01d8e351e21fc0b))
+
+## [1.12.0](https://github.com/0xPlayerOne/code-foundry/compare/v1.11.0...v1.12.0) (2026-09-09)
+
+
+### Features
+
+* **cloudflare:** verify candidates before protected version promotion ([#535](https://github.com/0xPlayerOne/code-foundry/issues/535)) ([5dd9afa](https://github.com/0xPlayerOne/code-foundry/commit/5dd9afa8418718823844875b0aedce926b887184))
+
 ## [1.11.0](https://github.com/0xPlayerOne/code-foundry/compare/v1.10.1...v1.11.0) (2026-09-09)
 
 

package/README.md

@@ -76,12 +76,13 @@ The standard workflow triggers are:
 
 Automated feature/fix and staging-promotion pull requests open as drafts.
 The trusted Draft Guard is a fallback for manually created or reopened ready
-PRs and for new commits to ordinary ready PRs: it converts them to drafts
-without checking out PR code. It verifies the event head and update timestamp
-before changing state, and excludes Release Please version PRs whose release
-workflow owns readiness. Pull-request validation runs only on the
-ready-for-review transition. Converting a PR to draft runs only the lightweight
-cancellation control. Scheduled and manually dispatched audits are unaffected.
+PRs: it converts them to drafts without checking out PR code. It verifies the
+event head and update timestamp before changing state, and excludes Release
+Please version PRs whose release workflow owns readiness. Pull-request
+validation runs on the ready-for-review transition and on new commits while a
+PR remains ready; draft updates allocate no validation runner. Converting a PR
+to draft runs only the lightweight cancellation control. Scheduled and manually
+dispatched audits are unaffected.
 
 Jobs are language-aware and skip irrelevant setup inside the applicable
 aggregate checks. TypeScript uses Oxlint, Oxfmt, and Bun's native

package/docs/CONFIGURATION.md

@@ -179,15 +179,23 @@ shards. Do not split a single crate by arbitrary non-Rust directories: use
 ## Cloudflare Workers deployments
 
 Repositories that deploy to Cloudflare Workers can opt into GitHub-native
-deployments (Preview/Production environments with deployment statuses, like
-Vercel's integration) by adding a small caller for the runtime's reusable
-`cloudflare-deploy.yml` workflow. The workflow runs `wrangler versions upload`
-for pull-request previews and `wrangler deploy` for production, records a
-GitHub deployment plus status with the workers.dev URL, and respects
-`CI_BILLING_PAUSED`. It requires the `CLOUDFLARE_API_TOKEN` and
-`CLOUDFLARE_ACCOUNT_ID` secrets in the consumer repository. Bun consumers may
-also pass `build-script`, `install-working-directory`, and `bun-version`; the
-runtime installs the frozen lockfile and builds the Worker before invoking
+verified delivery (fixed `Preview`/`Production` environments, candidate
+verification, and version-identity promotion) by adding a caller for the
+runtime's reusable `cloudflare-delivery.yml` workflow. Use the same immutable
+40-character Code Foundry commit SHA for both the reusable workflow ref and
+`runtime-ref`; configure required reviewers and branch restrictions on the
+`Production` environment. The workflow requires the
+`CLOUDFLARE_API_TOKEN` and `CLOUDFLARE_ACCOUNT_ID` secrets in the consumer
+repository. See [Verified Cloudflare delivery](./cloudflare-delivery.md) for
+binding policy, canary, rollback, and evidence requirements.
+
+The legacy `cloudflare-deploy.yml` workflow remains available for direct
+(unverified) deployments. It runs `wrangler versions upload` for previews and
+`wrangler deploy` for production, records a GitHub deployment plus status, and
+respects `CI_BILLING_PAUSED`. Its legacy-compatible Wrangler default is `latest`;
+callers should prefer `local` or provide an exact `wrangler-version` for
+reproducibility. Bun consumers may pass `build-script`, `install-working-directory`, and `bun-version`;
+the runtime installs the frozen lockfile and builds the Worker before invoking
 Wrangler. Bun-backed callers invoke Wrangler through `bunx` so OpenNext's
 production delegation resolves the workspace-local `opennextjs-cloudflare`
 binary; callers without `build-script` retain the npm/npx path.

package/docs/PERFORMANCE.md

@@ -15,9 +15,9 @@ belong to the run that produced them, not the source tree.
 | Format, lint, type-check, and build |   15 s | Bound the local CI feedback loop                     |
 | Runtime dependencies                |      0 | Keep the installed CLI dependency-free               |
 | Development dependencies            |      4 | Prevent unreviewed toolchain growth                  |
-| Packed artifact                     | 200 kB | Bound registry transfer and install cost             |
-| Unpacked artifact                   | 750 kB | Bound installed footprint                            |
-| Packed files                        |     80 | Detect accidental release contents                   |
+| Packed artifact                     | 210 kB | Bound registry transfer and install cost             |
+| Unpacked artifact                   | 800 kB | Bound installed footprint                            |
+| Packed files                        |     90 | Detect accidental release contents                   |
 
 The performance workflow disables build-cache reads and writes for this task.
 That makes timing comparisons independent of a warm protected-branch cache and

package/docs/README.md

@@ -14,6 +14,7 @@ its own names, environments, and deployment details.
 - [Caching and remote caching](CACHING.md)
 - [Performance budgets and baselines](PERFORMANCE.md)
 - [Required capabilities and task evidence](required-capabilities.md)
+- [Declarative fleet inventory and staged rollouts](fleet-rollouts.md)
 
 ## Repository-specific documentation
 

package/docs/WORKFLOWS.md

@@ -15,19 +15,19 @@ pull_request:
   # direct topology: branches: [main]
 ```
 
-The generated validation caller listens for `ready_for_review` and `push` to
-`main`. Draft pull requests register no validation checks and allocate no
-validation runner; main pushes run only the default-branch CodeQL lane, while
-full validation remains pull-request-only.
-A separate lightweight Draft Guard runs from the trusted base branch on
-`opened`, `reopened`, and `synchronize`; it converts ordinary ready pull
-requests back to draft without checking out pull-request code. It rechecks the
-current head and update timestamp before mutating state, so a stale event
-cannot undo a later draft or ready transition. Release Please version heads are
-excluded because the release workflow owns their state. A separate draft-control
-caller listens for `converted_to_draft` and cancels queued or running
-pull-request workflows without creating skipped validation jobs. Marking a pull
-request ready again starts validation for the current head.
+The generated validation caller listens for `ready_for_review` and
+`synchronize`. Its jobs require the pull request to remain ready, so draft
+updates allocate no validation runner; main pushes run only the default-branch
+CodeQL lane, while full validation remains pull-request-only. A separate
+lightweight Draft Guard runs from the trusted base branch on `opened` and
+`reopened`; it converts ordinary ready pull requests back to draft without
+checking out pull-request code. It rechecks the current head and update
+timestamp before mutating state, so a stale event cannot undo a later draft or
+ready transition. Release Please version heads are excluded because the
+release workflow owns their state. A separate draft-control caller listens for
+`converted_to_draft` and cancels queued or running pull-request workflows.
+Marking a pull request ready starts validation, and each new commit on a ready
+pull request starts it again for the current head.
 
 The separate `validation-audit.yml` caller is pinned to the configured released
 runtime and handles scheduled and manual audits:
@@ -108,7 +108,7 @@ opt in or out without a code change.
 | Security    | Profile, audits, and public-only Dependency Review                |
 | CodeQL      | GitHub-native code scanning, kept separate from CI                |
 | Draft PR    | Create/update development pull requests                           |
-| Draft Guard | Keep ordinary PRs draft until `ready_for_review`                  |
+| Draft Guard | Keep opened/reopened ordinary PRs draft until `ready_for_review`  |
 | Release PR  | Promote `staging` into `main` (staging-release topology only)     |
 | Release     | Release Please, GitHub release, and optional npm publication      |
 

package/docs/cloudflare-delivery.md

@@ -0,0 +1,188 @@
+# Verified Cloudflare delivery
+
+The opt-in `cloudflare-delivery.yml` workflow builds and uploads a candidate,
+validates its actual version bindings, runs an HTTP smoke probe and the required
+repository-owned verification command, then promotes **that version ID** after
+GitHub environment approval. Production promotion uses the Cloudflare deployment
+API and never rebuilds the application. The existing `cloudflare-deploy.yml`
+remains available for direct deployments and initial provisioning.
+
+## Adoption
+
+Call the new reusable workflow using an immutable, reviewed 40-character Code
+Foundry commit SHA and pass the same `runtime-ref`. Required inputs are
+`worker-name`, `artifact-path`, and `verify-command`.
+
+```yaml
+jobs:
+  delivery:
+    # Replace REVIEWED_SHA with the same reviewed 40-character SHA in both places.
+    uses: 0xPlayerOne/code-foundry/.github/workflows/cloudflare-delivery.yml@REVIEWED_SHA
+    permissions:
+      contents: read
+      deployments: write
+    with:
+      runtime-ref: REVIEWED_SHA
+      mode: production
+      worker-name: company-site
+      artifact-path: dist
+      verify-command: '["bun", "run", "test:deployed"]'
+      production-url: https://example.com
+      smoke-path: /health
+      canary-percentage: 10
+      canary-verify-command: '["bun", "run", "test:canary"]'
+    secrets:
+      CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
+      CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
+```
+
+`artifact-path` is relative to `working-directory`; `install-working-directory`
+selects the lockfile root. The selected output tree is hashed before and after
+upload; changes during upload fail. Include all built code/assets in that tree
+and disable duplicate custom build steps. This digest identifies the declared
+local build tree, not a Cloudflare-signed digest of every uploaded configuration
+field. The Worker version ID is the authoritative identity for promotion.
+
+Wrangler defaults to the installed, lockfile-resolved version. Explicit overrides
+must be exact versions, never `latest`, floating majors, or semver ranges. Pin a
+Wrangler version supporting `WRANGLER_OUTPUT_FILE_PATH` and version-1
+`version-upload` records. Missing preview URLs and output-schema mismatches fail.
+Bun remains the installation path, consistent with the existing deploy workflow.
+
+The repository verification command receives `BASE_URL` and
+`FOUNDRY_DEPLOYMENT_PHASE` (`candidate`, `canary`, or `production`). It must check
+critical journeys, redirects, assets, and application-specific behavior. The
+built-in smoke probe requires a successful 2xx response and does not follow
+redirects. Deploy credentials are not supplied to verification steps and are
+removed from the verification child environment as defense in depth. Install any
+browser binaries required by your verification command explicitly.
+
+When `canary-percentage` is below 100, `canary-verify-command` is required and
+must prove that the live request served the candidate rather than the baseline.
+It receives `FOUNDRY_EXPECTED_VERSION_ID`, `FOUNDRY_DEPLOYMENT_ID`, and
+`FOUNDRY_CANARY_PERCENTAGE`; use a version-aware response/header or an equivalent
+application check. A command that only observes a successful production URL is
+not sufficient.
+
+## Approvals, ordering, and evidence
+
+Create and protect the fixed `Preview` and `Production` GitHub environments
+before adoption. The workflow references them at the **job** level; naming an
+environment does not itself configure reviewers or branch restrictions. Configure
+required reviewers and branch restrictions on `Production` separately. Production
+execution requires the current default-branch commit and
+rechecks freshness after approval and before final promotion. Fork PRs and
+`pull_request_target` execution are excluded.
+
+Per-repository/Worker/mode concurrency never cancels a running promotion. GitHub
+concurrency is not a FIFO queue; stale-source rejection is still necessary.
+Other deployment systems and dashboard edits are outside this lock. The helper
+also checks that its deployment has not been replaced before a subsequent
+promotion or rollback, but the Cloudflare API check/write is not an atomic CAS.
+Migrate one application to one deployment owner; do not leave competing legacy
+and new production workflows active.
+
+Outputs include preview URL, exact version ID, source SHA, declared build-tree
+SHA-256 digest, Cloudflare deployment ID, and GitHub application deployment ID.
+Explicit application deployment records receive in-progress and success/failure
+statuses, in addition to GitHub's environment-job records. Sanitized candidate and
+production JSON evidence is uploaded even on failure. Binding values, API bodies,
+and credentials are not copied into those reports. Forced runner termination may
+prevent final status steps; the GitHub job still reflects cancellation/failure.
+
+## Stateful resources and isolation
+
+Without a policy file, non-resource bindings (for example strings, secrets, and
+static assets) are allowed; resource/service bindings fail closed. The uploaded
+version's actual bindings are inspected through the Cloudflare API. Durable
+Object bindings or exports are rejected: use a repository-specific migration and
+preview workflow instead of pretending version preview supports that topology.
+
+A reviewed read-only policy can allow smoke testing a candidate that shares
+production resources:
+
+```json
+{
+  "schemaVersion": 1,
+  "readOnlyBindings": [{ "name": "DB", "type": "d1" }],
+  "rollbackSafe": false
+}
+```
+
+Pass its relative path as `binding-policy-file`. This declaration is **not a
+sandbox**: the repository owner must ensure its test routes cannot mutate shared
+data. A version preview does not automatically create isolated KV, R2, D1, or
+service resources, and a GET route can still have side effects.
+
+For separately provisioned preview Workers, `isolatedBindings` entries can compare
+the actual binding's resource identifiers with expected preview identifiers and
+assert that they differ from declared production identifiers:
+
+```json
+{
+  "schemaVersion": 1,
+  "isolatedBindings": [
+    {
+      "name": "DB",
+      "type": "d1",
+      "expected": { "id": "preview-database-id" },
+      "production": { "id": "production-database-id" }
+    }
+  ]
+}
+```
+
+Use the field names returned for that binding type by the Version API. Resource
+provisioning and the correctness of production-identifier declarations remain
+repository-owned. Isolated preview bindings are rejected in production mode to
+prevent accidentally promoting staging resources. A version from a different
+Worker cannot be promoted across Workers; production mode uploads and tests its
+own candidate on the production Worker with reviewed read-only tests.
+
+## Canary and rollback policy
+
+A percentage below 100 first routes that share to the candidate, verifies it,
+and then promotes the same version to 100 and verifies again. A canary requires
+one prior baseline serving 100% and the explicit `canary-verify-command` above.
+A single load-balanced HTTP request may hit the old version; the command must
+observe the expected version ID. Set `canary-percentage: 100` when that
+version-aware observability is not configured.
+
+Automatic rollback is off. Enabling `auto-rollback` also requires an explicit
+`rollbackSafe: true` policy and both current and prior versions to be free of
+stateful bindings/DO exports. The policy must additionally account for external
+side effects that binding inspection cannot detect. Rollback restores the exact
+previous traffic split only when this run's deployment is still current. Failure
+remains a failed deployment even after rollback. Resource data, migrations,
+external API side effects, routes, and non-versioned settings are never rewound.
+The evidence file records prior versions for manual recovery when automation is
+unsafe or unavailable. Recovery itself must be verified operationally.
+
+This workflow targets already-provisioned Workers with version previews enabled.
+Manage initial Worker/route/trigger setup and non-versioned settings separately;
+the deployment API intentionally changes version routing only.
+
+## Legacy workflow hardening
+
+`cloudflare-deploy.yml` now uses real job environments, non-cancelling concurrency,
+structured Wrangler output, exact/local Wrangler selection, reusable outputs, and
+in-progress/failure deployment records. Its legacy-compatible default remains
+`latest`; callers should prefer `local` or an exact version for reproducibility. A
+production URL can be supplied with `deployment-url` when API output contains only
+route patterns. It is still a **direct, unverified deployment**; adopt
+`cloudflare-delivery.yml` for candidate verification and guarded promotion.
+
+## References and testing
+
+The implementation follows Cloudflare's structured Wrangler output and version
+routing APIs:
+
+- https://developers.cloudflare.com/workers/wrangler/system-environment-variables/
+- https://developers.cloudflare.com/workers/versions-and-deployments/
+- https://developers.cloudflare.com/api/resources/workers/subresources/scripts/subresources/versions/methods/get/
+- https://developers.cloudflare.com/api/resources/workers/subresources/scripts/subresources/deployments/methods/create/
+
+Run `node --test test/cloudflare-delivery.test.mjs`. Tests use deterministic API
+responses and never deploy a Worker. Before production rollout, run the new
+workflow against a disposable Worker and protected test environments, including
+smoke failure and rollback scenarios.

package/docs/fleet-rollouts.md

@@ -0,0 +1,139 @@
+# Declarative fleet inventory and staged rollouts
+
+Place `code-foundry-fleet.json` in the directory passed to `--root`. Its presence
+opts that fleet into inventory-based discovery and controlled upgrades, without
+changing legacy directory discovery for existing users.
+
+```json
+{
+  "schemaVersion": 1,
+  "cohorts": ["canary", "applications"],
+  "repositories": [
+    {
+      "repository": "owner/package-canary",
+      "path": "packages/package-canary",
+      "cohort": "canary",
+      "profile": "published-package",
+      "expected": { "git_workflow": "direct" },
+      "requiredCapabilities": ["unit", "performance"],
+      "validation": [
+        ["bun", "install", "--frozen-lockfile"],
+        ["bun", "run", "test:unit"],
+        ["bun", "run", "test:consumer"],
+        ["bun", "run", "performance:check"]
+      ],
+      "requiredChecks": ["Validation / Gate"]
+    },
+    {
+      "repository": "owner/application",
+      "path": "applications/application",
+      "cohort": "applications",
+      "validation": [
+        ["bun", "install", "--frozen-lockfile"],
+        ["bun", "run", "type-check"],
+        ["bun", "run", "test:unit"]
+      ],
+      "requiredChecks": ["Validation / Gate"]
+    }
+  ]
+}
+```
+
+Repository names in the example are placeholders. Populate the actual fleet
+before use. Paths are relative to the manifest, may be arbitrarily nested, and
+must not escape through `..`, absolute paths, or symlinks. Missing checkouts and
+origin mismatches remain visible as blocked inventory entries rather than silently
+disappearing. There is no automatic clone or repository-settings mutation.
+
+`profile` is a descriptive inventory annotation; it does not install tools or
+activate a quality profile. `expected` maps scalar `.github/code-foundry.yml` keys
+to desired values; `requiredCapabilities` audits declarations in that same file.
+The runtime-upgrade operation does not silently author missing capability policy.
+Adopt those requirements in consumer repositories before requiring them here.
+
+## Commands
+
+```sh
+code-foundry fleet status --root /path/to/fleet
+code-foundry fleet upgrade --root /path/to/fleet --dry-run
+code-foundry fleet upgrade --root /path/to/fleet --create-pr
+```
+
+Run from the intended released Code Foundry installation/checkout. The existing
+source-version guard still rejects mismatched `--version` requests. Manifest mode
+requires `--create-pr` or `--dry-run` and never syncs original checkouts in place.
+`--force` does not bypass dirty-tree safety in manifest mode. Dry-run reports
+inventory, target version, and configuration drift without network calls, running
+consumer commands, or modifying files. Status likewise audits local facts; it does
+not pretend to verify remote branch protection or environment settings.
+
+The first incomplete cohort is the only cohort allowed to create PRs. All
+non-excepted members of each earlier cohort must have a matching managed upgrade
+PR that is merged, successful explicitly named required checks on its head SHA,
+no still-pending/failed checks, and the target runtime/configuration still present
+on its current base branch. Neutral/skipped required checks do not qualify.
+Unknown, inaccessible, closed-without-merge, stale, or failed evidence does not
+unlock subsequent cohorts. One local validation failure stops remaining work.
+
+Each repository must supply explicit validation argv arrays. Include locked
+installation, application checks, and genuine consumer compatibility tests where
+relevant. No shell splitting is used. Commands run in an isolated detached
+worktree, have bounded execution time, and must not rewrite the candidate source.
+Validation is not a security sandbox: commands run as the invoking user with its
+inherited environment and network access. Treat the manifest and every validation
+command as trusted code; do not use this feature with unreviewed manifests or
+credentials that the checks should not access.
+Only files changed by Code Foundry sync are staged; generated test evidence and
+other untracked files are not swept into the commit. A commit-hook change to the
+validated Git tree is rejected before publishing.
+
+This implementation does not create an automatic scheduler, mark PRs ready,
+merge PRs, lower checks, or bypass review. After reviewing and validating canaries,
+merge their PRs normally and run the fleet command again to advance the cohort.
+A repository already at the target version with no managed PR does not establish
+canary evidence; choose a real upgrade canary rather than treating an empty diff
+as successful rollout validation.
+
+## Resuming and intentional exceptions
+
+The target version and complete repository policy produce a deterministic branch
+and PR marker. Repeated runs return an existing matching open PR instead of
+creating duplicates. If push succeeded but PR creation failed, the next run
+recognizes the managed commit and recorded tree identity, reruns consumer
+validation, and creates the missing **draft** PR without force-pushing. Unknown
+branches or commits with mismatched tree markers are preserved and blocked for
+manual review. Local managed refs preserve committed work after a failed push.
+The marker is an ownership/recovery guard, not a cryptographic signature.
+
+PR creation is draft-first in both manifest and legacy discovery modes. A PR that
+a human has already made ready is not silently converted back or modified.
+
+An entry may include a reviewed time-limited exception:
+
+```json
+{ "exception": { "reason": "Pending consumer compatibility work", "expires": "2026-10-01" } }
+```
+
+Exceptions appear explicitly in inventory/rollout output. Expired/invalid dates
+fail parsing. The command's existing `--exclude` flag is also honored. Excluding
+all canaries never satisfies a canary gate or unlocks later cohorts. Update the
+manifest deliberately when cohort membership or compatibility policy changes.
+
+## Evidence and tests
+
+Upgrade output is schema-versioned JSON with target version, aggregate status,
+per-repository cohort/status, PR link, and local validation command exit statuses.
+Failed command output is not copied into reports, avoiding accidental credentials
+in logs; reproduce the declared command locally for full debugging output. A
+failed rollout returns a nonzero exit status. Pending PRs are not failures and do
+not grant permission to advance a cohort. Worktree cleanup failures preserve the
+isolated path and report it rather than deleting unknown paths.
+
+`node --test test/fleet-manifest.test.mjs` includes actual local Git repositories,
+bare remotes, isolated worktrees, validation failure, orphan-branch recovery,
+clean-original preservation, and canary advancement. Only GitHub responses are
+fixture-backed; no real fleet repositories or remote PRs are modified by tests.
+
+GitHub CLI contracts:
+https://cli.github.com/manual/gh_pr_list
+https://cli.github.com/manual/gh_pr_create

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "code-foundry",
-  "version": "1.11.0",
+  "version": "1.13.0",
   "description": "A fast, language-aware repository factory for agent-ready workflows, testing, security, and release automation.",
   "homepage": "https://github.com/0xPlayerOne/code-foundry#readme",
   "bugs": {