changelog

{data.name} Sami Fouad made a commit to dekaruntime/create-deka-app

publish: pre-flight every package before the first publish

npm has no multi-package transaction and the OIDC credential cannot unpublish, so all-or-nothing is decided before the first write: every package in the run's set is checked for a stamped version, no placeholder dependency pins, a packable tarball, and (platform packages) the binaries actually inside it. One failure means nothing is published.

Verified
+54 -0
Sep 16

{data.name} Sami Fouad made a commit to dekaruntime/create-deka-app

Merge pull request #20 from dekaruntime/fix/autopilot-hardening

publish: make the hourly schedule real, serialize runs, pin npm major

Verified
+58 -18
Sep 16

{data.name} Sami Fouad made a commit to dekaruntime/create-deka-app

publish: make the hourly schedule real, serialize runs, pin npm major

The schedule event fell into the resolve step's 'unsupported event' branch, so the hourly fallback could never publish anything. The publish job is now a two-leg matrix (dsc, then deka; max-parallel 1): a tag or dispatch names one family and the other leg no-ops, the schedule runs both. Job-level concurrency keeps two publish runs from overlapping. npm is pinned to major 12 instead of @latest.

Verified
+58 -18
Sep 16

{data.name} Sami Fouad made a commit to dekaruntime/create-deka-app

Merge pull request #19 from dekaruntime/fix/lockstep-single-path

Single publish path: remove publish.yml, make publish-runtime.yml resumable

Verified
+184 -169
Sep 16

{data.name} Sami Fouad made a commit to dekaruntime/create-deka-app

publish: straight to latest, drop the next→promote step

Trusted publishing's OIDC credential only covers npm publish; npm dist-tag add fails with E401 (seen on run 35056200218, dsc 0.53.5). Publish order is the safety instead: platform packages, then the launcher, then create-deka-app, each read back before the next.

Verified
+21 -22
Sep 16

{data.name} Sami Fouad made a commit to dekaruntime/create-deka-app

Single publish path: one workflow, resumable, never commits a version bump

create-deka-app was reachable through three separate GitHub Actions surfaces: publish.yml's standalone v* tag (a scaffolder-only release requiring a hand-bumped version committed to git), publish-runtime.yml's lockstep deka family run (which stamps create-deka-app's version in the working tree only, never committing it), and ci.yml (a separate test job). The two publish paths disagreed on how a version gets set, and the repo must never carry a real version bump in git -- so this collapses everything into the single file publish-runtime.yml (kept at that exact name: npm trusted publishing for the 8 @dekaruntime/* packages is configured against it), with two jobs:

  • test: runs on every trigger (pull_request, push to main, tag pushes, repository_dispatch, schedule, workflow_dispatch) -- checkout, Node 22, the same npm install -g npm@latest the publish job uses, npm ci, npm test, and the usage-message assertion that used to live in publish.yml. contents: read only, no environment, no id-token.
  • publish: needs: test, gated with if: github.event_name != 'pull_request' && github.event_name != 'push' || startsWith(github.ref, 'refs/tags/') so it only runs for a deka-v*/dsc-v* tag push, repository_dispatch, schedule, or workflow_dispatch -- never a pull_request or a plain push to main. Everything already in this job is unchanged (resolve version, resumable check, dsc pin, download/verify, stamp all 9 packages, publish tolerant of already-published, read back, promote to latest, tag), minus the now-redundant standalone "Test create-deka-app" step.

Root package.json now carries a "0.0.0" placeholder instead of a real semver, matching the "never commit a version bump" rule: the real version only ever exists in the working tree during a publish job run, stamped by its "Stamp versions" step. The runtime pin logic (src/scaffold.js resolveRuntimeVersion) needed no change -- it already just forwards whatever ownVersion it's given, so it keeps pinning the stamped version at publish time and 0.0.0 in every other context (local dev, tests). The registry-lookup fallback for a create-deka-app release that ships before its matching runtime build (resolveLatestRuntimeVersion) is unaffected and stays in place.

Also added package-lock.json (previously absent -- the repo has zero dependencies, so npm install never generated one) so npm ci in the new test job has something to install from.

publish is made resumable, so a half-completed run (for example: the 8 runtime packages reach next/latest but create-deka-app's own publish step fails) is finished by the next run instead of being skipped forever:

  • "Check whether this version is already published" now skips only when every package in the run's set (the three platform packages, the launcher, and create-deka-app for a deka run) is already at dist-tags.latest == VERSION, instead of checking just the launcher package. A partially-done run therefore reports skip=false and runs again.
  • Every npm publish step now checks npm view "<name>@${VERSION}" version first and skips its own publish (logging why) when that exact version is already on the registry, so a resumed run doesn't fail on npm's "cannot publish over the previously published versions" (E403/EPUBLISHCONFLICT) refusal for packages a prior run already published.

Tested: npm ci && npm test passes all 69 tests with the placeholder version in the tree (including the e2e and unit tests that read create-deka-app's own version and assert the scaffolded pin matches it). Workflow YAML validated with ruby -ryaml and actionlint, both clean.

Verified
+167 -151
Sep 16

{data.name} Sami Fouad made a commit to dekaruntime/create-deka-app

Merge pull request #18 from dekaruntime/feat/lockstep-versioning

Lockstep-version create-deka-app with @dekaruntime/deka

Verified
+392 -107
Sep 16

{data.name} Sami Fouad and Claude Opus 5 made a commit to dekaruntime/create-deka-app

Lockstep-version create-deka-app with @dekaruntime/deka

create-deka-app now versions in lockstep with the deka runtime it scaffolds: create-deka-app@X.Y.Z always pins @dekaruntime/deka@X.Y.Z -- its own version -- rather than a separate 0.0.x release line resolved from a registry lookup at scaffold time. The pin is now reproducible and needs no network call; the registry lookup from PR #11 survives only as a fallback for the case where the exact matching runtime version isn't published yet, with a clear log message and never a silently-pinned nonexistent version (the 0.0.3 ETARGET bug).

publish-runtime.yml's deka-family run now also stamps, tests, and publishes create-deka-app as part of its all-or-nothing boundary -- after the launcher, included in the registry read-back and the next -> latest promotion. dsc-family runs and the standalone v* tag path (publish.yml) are unchanged.

Claude-Session: https://claude.ai/code/session_01XHuN9xFKcoJaoTJfBwxsb1

Verified
+392 -107
Sep 16

{data.name} Sami Fouad made a commit to dekaruntime/create-deka-app

Merge pull request #17 from dekaruntime/release/0.0.6

release: create-deka-app 0.0.6

Verified
+82 -1
Sep 16

{data.name} Sami Fouad and Claude Opus 5 made a commit to dekaruntime/create-deka-app

release: create-deka-app 0.0.6 (next steps say deka dev)

Claude-Session: https://claude.ai/code/session_01XHuN9xFKcoJaoTJfBwxsb1

Verified
+82 -1
Sep 16