Your first developer change

The fastest way to get oriented in an unfamiliar codebase is a small change you can verify end to end, not a long read through the architecture docs first. This guide is that change: run the fictional demo, see where code lives, and edit the existing example module. Nothing in this first exercise adds a database table or sends anything externally.

Start the app

You need Git, Node.js 22.16 or later, npm and an editor. Start from the published main branch for a local experiment.

node --version
npm --version
git clone https://github.com/JohnConnorCode/accelerate-site.git
cd accelerate-site
git rev-parse HEAD

For an assigned Feature Board task, use the approved repository base and exact commit in its live execution packet. Resolve a mismatch before changing code.

Then install and start the app:

npm ci
npm run dev

Run the remaining commands from the cloned repository, where package.json lives. npm ci installs the versions recorded in the lockfile. npm run dev starts the local development server; it does not publish the application.

Open the URL printed by the terminal, then visit /demo/command-center. You should see a fictional business workspace. Follow your first workflow to learn the behavior before changing code. Stop your own server with Control-C when finished.

Find the right files

You want to change…	Start here
A page or request entrypoint	src/app/
Reusable interface pieces	src/components/
Business rules and reusable operations	src/lib/revenue-os/
Module registration	extensions/
Public product guides	src/content/docs/ and its manifest.ts
Database structure	Ordered migrations and the migration manifest

Read docs/NORTHSTAR.md and then AGENTS.md before implementation. For coordinated repository work, follow the live Feature Board contract; a local experiment is not a claimed or completed board ticket.

Make one small change

The repository includes an Inventory example. Its manifest registers a page and workspace toggle; it does not implement stock storage or automatic reordering.

1. Open src/app/admin/example-inventory/page.tsx in your editor.
2. Find the heading “This page is registered by a manifest” and change it to “My first workspace extension”. Save the file.
3. Read extensions/example-inventory.module.json. Its routes field names the page you edited. It ships with defaultEnabled: false; leave that setting unchanged for this exercise.
4. In another terminal in the repository, run the checks below. These confirm registration consistency; they do not prove database permissions or a rendered page.

npm run verify:extensions
git diff --check
git diff -- src/app/admin/example-inventory/page.tsx

The diff should contain only your intended text change. You do not need to regenerate module registration when only page text changes.

See the extension in a workspace

The public demo demonstrates selected fictional workflows. To inspect this admin extension, use a connected local installation with an administrator account.

Open /admin/integrations, enable the Inventory example for your test workspace, and visit /admin/example-inventory. Confirm your heading appears. Disable the module and confirm the route refuses access. This is a workspace feature check; it does not require enabling the example for other workspaces.

Turn the example into a real feature

Add a module covers a new manifest and route. A real feature also needs explicit business behavior, validation, authorization, storage if required, and meaningful tests. A manifest does not create those for you.

Keep business writes in the shared domain services so the UI, AI tools, and integrations use the same rules. External effects need approval where required, idempotency, and a truthful result. Read the engineering and tenancy contracts linked from AGENTS.md before adding a write path.

Run the affected checks and the repository's required verification before submitting application code. Use one heavy job at a time or CI; do not start parallel builds or copy dependency trees to work around resource limits.

Keep developing through the backlog

You can simply tell a coding agent: “Pick up work from the backlog and go until it is completed and committed. Follow protocol.” The repository entrypoint defines that as a complete execution request. The agent continues its current task or selects eligible interrupted work before starting a ready card. It uses an isolated worktree, follows the live packet, verifies the result, commits the exact change and submits evidence for review. Internally this uses agent:go, but you do not need to provide a ticket key or command name.

Run npm run dev:doctor to check local readiness and npm run dev:doctor -- --board for a read-only board connection check. Pickup, diagnostics, heartbeat and submission reuse the configured private profile across worktrees. An owner-authorized local profile uses the existing named-project configuration. A remote contributor configures project-scoped HTTPS access once through the setup workflow and does not need the owner’s database credentials. Agents never ask you to paste secrets into chat. If a feature checkout has unfinished work, preserve it and start a new session from a clean published-main control checkout.

If an agent runs out of time or credit, its next replacement should be able to continue from saved source and remaining work. With this release's recovery schema and project policy enabled, the runner resumes an expired task from its latest checkpoint, a saved copy of unfinished source. It preserves the previous checkout so work newer than that copy can still be inspected. Initial pickup and progress updates save checkpoints; newly created source files need explicit inclusion.

The internal runner handles continuation, selection and claim for the natural-language request. For explicit diagnostics, npm run agent:status and npm run agent:show -- --card <key> remain available; agent:next is the compatibility command for a named card. Follow the live acceptance criteria, use the emitted commands to renew ownership, and submit named checks and the exact commit with agent:complete. For long checks, the bounded job wrapper keeps ownership current while the command runs. The agent handoff guide explains source checkpoints and attempt-specific commands. Submission, review, merge and deployment are separate recorded steps. The full command contract is in AGENTS.md and its linked developer handoff.

Every feature change also updates the organized public guides, product changelog and Command Center descriptions in the same pull request. Keep planned capabilities clearly separate from available behavior. Report new gaps through the live board so the next contributor has a concrete task and verification criteria.

Next: Add a module. If something failed, use Troubleshooting.

Keep agent work within machine capacity

The shared resource runner allows one heavy job at a time across worktrees. An optional local machine supervisor adds a queue and process identity checks for registered agent sessions. It starts off and requires no service credentials. It is separate from Feature Board assignment: continue using the ordinary backlog runner to claim and complete work.

The supervisor can pause a registered producer without terminating it, preserve a paused session during recovery, and report unmanaged launch paths. It does not install hooks into every agent, reconstruct lost conversations, or provide OS-level isolation. Its guide explains configuration, recovery, and the tested limits.