Dev onboarding
Get productive in the Capxul monorepo and find the right owner before editing.
This page is for contributors to
Xelmar-tech/infrastructure.
Consumer integration starts in the SDK tutorial.
Prerequisites
- Node 22.12 or newer, as enforced by the root manifest.
- The package-manager version pinned by the root manifest.
- Vite Plus (
vp), installed with the workspace dependencies.
git clone git@github.com:Xelmar-tech/infrastructure.git
cd infrastructure
vp install
vp run check:fastOrient before changing code
- Read the root
CONTEXT.mdfor product language. - Use
CONTEXT-MAP.mdto find the package or application owner. - Read that workspace's
README.mdandCONTEXT.md. - Read repository canon only for the cross-package boundary you are changing.
- Read
AGENTS.mdbefore dispatching or acting as an agent.
The repository currently has ten packages under packages/ and seven
applications under apps/. Do not copy their inventory into a new document;
CONTEXT-MAP.md is the maintained owner index.
Commands
| Need | Command |
|---|---|
| Change-scoped gate | vp run check:pr --base <ref> |
| Pre-push gate | vp run check:fast |
| Full repository proof | CI-only check:full job |
| Package task | vp run --filter <workspace> <task> |
| Library artifact | vp pack |
| Application build | vp build |
The task graph is vite.config.ts#run.tasks. See
development and verification
for what each command proves.
Use check:pr for ordinary agent work. Bare vp run check:full refuses
locally before starting the expensive repository-wide proof.
Secrets and live work
Operator secrets live in ~/.config/capxul/secrets.env (shared base) plus
per-environment overlays ~/.config/capxul/secrets.<APP_ENV>.env
(development is the default), shared by all local worktrees. Never commit or
print them.
vp run secrets:init
vp run secrets:verify
vp exec bash scripts/capxul-env.sh <command> # the one way to run env-dependent commandsHermetic tests need no Docker or local database. Live proofs require the configured Convex deployment and provider credentials and prove only the named journey.
Before a PR
Follow the documentation workflow
to route changed facts to their owners and update every affected projection in
the same PR. Then run targeted proof, the change-scoped or repository gate, and
the repo-local two-axis code-review skill against the real PR base. Public UI
and documentation changes also require visual browser verification.