Reliable releases and consistent cycle data
- Release recovery handles temporary dispatch failures and reuses verified artifacts.
- Cycle membership updates preserve concurrent changes across the dashboard and MCP.
- Read and manage your own planning-log entries directly through MCP.
Full detail
- Cycle 83 — Reliable Releases and Cycle Data
- Discover landed work from fresh remote main, recover bounded transient workflow dispatch failures, and reuse verified immutable artifacts without rebuilding. Real ten-minute release timing remains to be measured.
- Delegate cycle membership from the dashboard, PostgreSQL adapter and hosted service to one transactional RPC, preserving concurrent roster edits.
- Read, edit and delete planning-log entries through MCP using exact entry IDs and author-scoped mutations.
Safe build recovery and less repeated work
- Completion failures tell you whether a report was saved before suggesting recovery.
- Planning keeps useful capability evidence without repeating identical descriptions.
- Release builds use stable cache paths and avoid duplicating runtime dependencies.
Full detail
- Cycle 82 — Faster Reliable Delivery
- Distinguish report writes that were not attempted, succeeded, or have an uncertain outcome before suggesting recovery.
- Collapse repeated capability descriptions while retaining distinct file information, changed deliverables, and task references.
- Use stable locked build staging, avoid a duplicate dependency-tree copy, bound streamed inventory hashing to four files, and yield while waiting for the exact qualified artifact. The ten-minute target still requires measured release evidence.
More reliable upgrades, with clear failure and waiting records
- Upgrades use the approved installer so installer fixes apply during the upgrade itself.
- Task lists and releases read less data while retaining task and cycle checks.
- Runner waits remain separate from failed installations, and original failure details are preserved.
- Release timing stops at verified live health, before later bookkeeping.
Full detail
- Upgrade through the approved candidate installer, preserving installer fixes during activation; artifact qualification now exercises the real activation preflight.
- Bound release integrity reads to the selected cycle and its Done tasks; board pages fetch heavy detail only for the displayed tasks.
- Treat queued CI as waiting, preserve original activation errors, and upload failed attempt receipts beside the immutable artifact.
- Measure verified live time before reconciliation, record admin health correctly, and avoid unrelated branch scans for an explicit release target.
Install skills for the AI clients you use
- Choose native skill directories explicitly while keeping local overrides and edited skills intact.
- Review context includes project conventions and relevant decisions for the reviewer to consider.
- Build attribution works through the existing MCP connection and keeps unknown identity valid.
- Validated release stages remain intact until activation.
Full detail
- Cycle 81 — Client compatibility and review context
- Install the pinned skill bundle into explicitly selected native directories for supported AI clients, preserving local overrides and edits.
- Deliver plugin-free attribution guidance on connect and require stronger completion evidence to name its exact turn or message.
- Include project conventions and relevant decisions in review context as findings for the reviewer to consider.
- Keep validated release stages intact until activation.
Failed installs are visible, and releases reach the live check sooner
- A failed install leaves one compact receipt with its source, elapsed time, stopping phase and redacted error.
- The read-only migration ledger check runs before artifact qualification, catching missing migrations before the expensive build.
- Detailed build diagnostics remain in the workflow log, while deployment receipts focus on health, configuration and rollback.
- Build reports keep runtime model evidence separate from caller self-reports.
Full detail
- Cycle 79 — Release reliability and attribution
- Failed installs now leave one compact receipt with the source commit, elapsed time, failed phase and redacted error; build details stay in the linked workflow logs.
- Check the live migration ledger before artifact qualification, so an unapplied migration fails before the slow build and before activation.
- Keep the ten-minute merge-to-live target and retain only the activation evidence needed to verify configuration, health checks and rollback.
- Build reports distinguish exact runtime model evidence from a caller's self-reported model.
Safer task ownership and clearer provider reporting
- Task ownership can change at any status, with each ownership update recorded atomically.
- Cost refresh failures preserve the last successful measurements, while malformed provider responses are reported as unknown instead of zero.
- Provider requests are bounded so healthy results can be saved independently of a stalled provider.
- Dashboard links distinguish projects with duplicate names, CSV exports preserve carriage returns, and private pull request lookup can use authorized OAuth access.
Full detail
- Cycle 398 — Ownership after review
- Transfer, reassign or unassign a task at any status, including In Review and Done, without reopening the work.
- Project owners can unassign any task, assign an unassigned task, or reassign to any eligible teammate.
- Every ownership change is one atomic write with an append-only audit record, from the dashboard or any MCP client.
- Cycle 80 — Provider, export, and project-link reliability
- Cost refresh failures preserve the last successful measurements; malformed provider responses remain unknown instead of becoming successful zeroes.
- Bounded provider requests let healthy results save even if another provider stalls.
- Dashboard exports preserve carriage returns, private pull request lookup can use authorized OAuth access, and project links keep duplicate names distinct.
Cycle 398: right-project writes, atomic credentials, and a light-first public site
- Dashboard task, review and cycle edits now bind to the project you are viewing instead of falling back to a default project.
- Connection tokens regenerate atomically, so concurrent requests can no longer leave a broken key behind.
- A stalled connection now names the real cause, including an expired or revoked credential, with the one action that fixes it.
- Public pages render the light-first brand by default, and the statusline helper is documented in the install runbook.
Full detail
- Cycle 398 — Authority, atomicity and light-first marketing
- Dashboard task, review and cycle edits bind to the project you are viewing instead of silently falling back to a default project.
- Connection tokens regenerate atomically, so concurrent requests can no longer leave a broken key behind.
- A stalled connection now names the real cause, including an expired or revoked credential, with the one action that fixes it.
- The statusline helper ships as a real, runnable command documented in the install runbook.
- Public pages default to the light-first brand. The separate dark-only landing palette on / and /pricing is a tracked follow-up.
VPS preflight cleanup no longer reports an unset local after activation
- The promotion preflight captures its cleanup path and keep flag before the EXIT trap runs after function scope ends.
- The Linux promotion integration test now fails if a successful activation emits an unbound-variable cleanup error.
Full detail
- Cycle 79 — Release reliability follow-up
- Capture preflight cleanup values when installing the EXIT trap, so successful server activation cannot end with an unbound-local cleanup error.
- Add a regression assertion to the Linux promotion integration test for this post-activation failure.
Release completion stays accurate when post-activation cleanup reports an error
- The release runner verifies the exact server receipt and health gates before accepting an activation command that returned nonzero.
- The ten-minute installation goal is recorded as a target, while visible progress allows longer work to continue.
- The activation cleanup trap now handles staging paths after their function scope ends.
Full detail
- Cycle 79 — Release reliability follow-up
- Fix the post-activation EXIT trap so it safely handles function-local staging variables after scope exit.
- Continue release verification when SSH exits nonzero only if the VPS receipt confirms the exact approved artifact activated and passed health gates.
- Treat ten minutes as a measured installation target; progress resets the bounded MCP inactivity timeout, while the stage timings and live receipt remain recorded.
Release checks follow the exact source tree across checkouts
- A completed full-gate qualification can be reused after moving the same repository tree to another checkout on the same platform and toolchain.
- The post-activation cleanup function ignores an unset staging path.
Full detail
- Full-gate receipts now follow the repository tree and pinned toolchain instead of a checkout path, avoiding repeat qualifications when release work moves to a clean checkout.
- Post-activation cleanup tolerates an unset staging path, so cleanup cannot turn a healthy activation into a failed release command.
Portable builds and credential-safe test runs
- Local builds invoke the pinned tools directly through the active Node executable across Windows, Linux, and macOS.
- Supabase-generated credentials are redacted from integration-test logs.
- Release artifact diagnostics identify changed files while preserving fail-closed digest checks.
Full detail
- Cycle 79 — Release reliability follow-up
- Explicit release targets no longer get diverted by generated untracked files; tracked edits still block release.
- Release packages prune volatile Next.js trace files and Python bytecode caches before manifest creation.
- When an immutable repeat digest differs, CI compares file manifests and reports changed, added, or removed paths while failing closed.
- Windows and POSIX local gates call the pinned build tools through the active Node executable, without workspace shim lookups.
- Disposable Supabase credentials are redacted from startup and function-server output.
Build completion no longer stalls on large projects
- Completing a build now reads only the current cycle's tasks instead of the entire project board, so it finishes reliably on projects with thousands of tasks.
- This unblocks the build-to-review flow for long-running projects, where completion previously failed before the task could reach review.
Full detail
- Cycle 397 — Core Authority & Write-Path Integrity
- Completing a build reads only the current cycle's tasks instead of the entire project board, so completion finishes reliably on projects with thousands of tasks and the build-to-review flow is unblocked.
Repeat release builds now verify the exact immutable artifact
- Public and admin Next.js build IDs and release manifest timestamps are tied to the source commit for reproducible packaging.
- A repeated build can reuse an existing release only when its commit, assets, digest, and Git tag all match.
- The ten-minute merge-to-live target is only claimed after a complete build, activation, and health verification.
Full detail
- Cycle 79 — Release reliability
- Public and admin dashboard build identities and artifact timestamps are derived from the source commit so repeat builds can produce the same immutable archive.
- Existing artifact reruns verify the exact commit, required assets, archive digest, and remote Git tag; any mismatch fails closed with both digests shown.
- The ten-minute merge-to-live target remains subject to an exact merged artifact build, repeated cache run, and verified server activation.
The release path now carries approved work forward and records its ten-minute result
- The workspace release runner exposes PAPI's explicit unfinished-task carry-forward choice.
- The off-host build uses a persistent npm cache, Turbopack for both dashboard roles, and deterministic fast artifact compression.
- The timing receipt reports whether merge-to-live met the ten-minute target; only a complete measured run can confirm it.
Full detail
- Cycle 78 — Release reliability follow-up
- The workspace release runner can explicitly carry unfinished cycle work forward, and the install receipt records whether merge-to-live met the ten-minute target.
- Keep the npm cache on the persistent build runner, use Turbopack for the off-host dashboard builds, and package the immutable artifact with deterministic fast compression.
- Preserve the exact artifact, checksum, hosted health checks, and VPS activation gates; this change does not claim the ten-minute target until the next complete run measures it.
Release builds get clearer cache evidence, with a new path into comparisons
- Build reports capture supported runtime model evidence so production activity can be attributed to its recorded source.
- Release logs show cache restoration and output sizes for both dashboard roles, with stable source timestamps for repeat builds.
- The landing page now links to the comparison hub, with a documented consent-aware method for measuring qualified signups.
Full detail
- Cycle 78 — Release reliability, model attribution and organic discovery
- Build reports now capture supported runtime model evidence instead of leaving production attribution empty.
- Release builds use stable cache keys and report cache availability and size for each dashboard role.
- Add a contextual path into the comparison hub and document a consent-aware method for measuring qualified signups.
Windows integration checks no longer rely on npx being on PATH
- The disposable Supabase test setup now runs the pinned npm CLI directly through Node.
- Regression coverage verifies cached npm selection and the Windows-safe invocation.
- The test gate now ignores generated Playwright transform files when linting changed source.
Full detail
- **Build and release reliability — **
- Resolve the pinned npm CLI directly through Node for disposable Supabase integration setup, avoiding the Windows
npx.cmd PATH failure.
- Add regression coverage for cached pinned npm selection and document the supported Windows invocation.
Releases finish faster with clearer proof and a ten-minute limit
- Accepted reviews can prove the exact landed commit when an older build receipt no longer matches the release branch.
- The full test result is reused across identical PR and merge trees, with platform and compiled output checks preserved.
- Merge CI and server artifact qualification start automatically; VPS installation has a hard ten-minute budget and uses native Windows SSH.
Full detail
- Release process — comparisons and deployment reliability
- Keep a release moving when a task build receipt names an older commit by accepting the exact commit from its later accepted review only when that commit is reachable from the freshly fetched release branch.
- Reuse full local qualification for an identical source tree across the PR head and GitHub merge commit, while still checking the platform, Node major, and compiled runtime fingerprint.
- Start exact-merge CI and the immutable Linux artifact build automatically from the merged, version-ready change so both are ready before installation.
- Bound the complete VPS install command to ten minutes, perform qualification and artifact checks before publishing the version tag, and use native Windows OpenSSH from the release runner.