Disclaimer: This project is fully generated with AI and OpenSpec in order to try agentic engineering. No code is verified by a human.
Opinionated initializer for TS-first SaaS projects.
Node.js 24 or newer is required before installing dependencies.
npm init lv48-app
# or
npx create-lv48-appThe initializer prompts for:
- project name
- target directory (defaults to the project name)
- whether to install dependencies
- whether to initialize a git repository
The base preset is applied automatically. The package manager is npm.
The base preset generates an npm workspaces monorepo:
<project>/
├── apps/
│ ├── web/ # React + Vite + Tailwind CSS v4, shadcn-ready
│ ├── site/ # Astro
│ └── api/ # Node + Hono
├── packages/ # reserved for future shared workspaces
└── package.json # root workspace manifest
All generated package manifests declare engines.node as >=24.0.0. The git repository is initialized with main as the initial branch when git initialization is selected.
Run the test suite:
npm testWatch mode:
npm run test:watchTests run through the built-in node:test runner.
Run the full release gate locally before merge or before debugging a release issue:
npm run release:checkThis runs:
npm run typechecknpm run buildnpm run testnpm run release:verify-packnpm run release:smoke
Every merge that should remain compatible with release-please must expose release intent through Conventional Commit metadata that CI can validate before merge.
Enforced merge policy:
- merge pull requests with squash so the final pull request title becomes the canonical Conventional Commit on
main - if maintainers intentionally use a non-squash merge path, every commit message in that branch must follow the same contract
- add
!or aBREAKING CHANGE:footer when the next release must be major
Supported release types:
feat-> minorfix-> patch
Non-release types:
buildchorecidocsrefactorstyletest
The workflow at .github/workflows/validateReleaseIntent.yml validates the pull request title first and falls back to commit-message validation when the title is not canonical.
Publishing uses the workflow at .github/workflows/publish.yml.
Publish flow:
- Merge pull requests into
mainwith Conventional Commit metadata thatrelease-pleasecan interpret. release-pleaseonmaincreates or updates the generated release pull request with version bump and changelog changes.- Merge the generated release pull request.
- The merged release commit on
maintriggers GitHub Actions publish. - GitHub Actions runs
npm ci. - GitHub Actions runs
npm run release:publish, which first executesnpm run release:check. - After all verification gates pass, GitHub Actions publishes with
npm publish --access public.
Required GitHub Actions setup:
- configure npm trusted publishing for this repository in npm
- allow GitHub Actions OIDC for npm publish
- keep workflow permissions
id-token: write,contents: write, andpull-requests: write
Notes:
- Public npm packages can be published from a private GitHub repository.
- npm provenance is not supported for GitHub Actions publishes from private repositories, so this workflow intentionally does not pass
--provenance. - Keep npm trusted publishing configured for the repository. If trusted publishing is unavailable, use an
NPM_TOKEN-based publish path instead of re-enabling provenance. - The generated release pull request is the only automation-owned release artifact in the repository.
- Re-running publish for the same merged release commit remains valid if a previous attempt failed after the release PR was created.
If any verification step fails, publish does not run.