faasjs-project-workflow

---
name: faasjs-project-workflow
description: 'Use when creating, configuring, reviewing, or onboarding a FaasJS project; working with create-faas-app, vp CLI, TypeScript or Vite config, feature folders, file and naming conventions, test placement, JSDoc/comments, or complete application slice workflow.'
---

# FaasJS Project Workflow

## Default Workflow

1. Read the project config and file layout before adding or moving files.
2. Keep features as vertical slices with UI, API, database changes, and tests close together.
3. Follow existing `tsconfig.json` aliases and Vite/Vitest configuration; do not invent new aliases without matching runtime config.
4. Place tests in `__tests__/` inside the feature or package area they protect.
5. Use public JSDoc only for package entrypoints or shared exports with non-obvious caller contracts.

## Load These References

- New project setup or onboarding: `references/guidelines/getting-started.md`.
- Supported stack and framework boundaries: `references/guidelines/curated-stack.md`.
- Complete vertical feature layout: `references/guidelines/application-slices.md`.
- File placement and extraction rules: `references/guidelines/file-conventions.md`.
- TypeScript, Vite, and shared tooling config: `references/guidelines/project-config.md`.
- CLI commands, type generation, migrations, test commands, and environment variables: `references/guidelines/cli-and-tooling.md`.
- Identifier, file, and directory names: `references/guidelines/naming-convention.md`.
- JSDoc and inline comment policy: `references/guidelines/code-comments.md`.
- Shared test-level and mock-boundary rules: `references/guidelines/testing.md`.

## Gotchas

- Tests, fixtures, and mocks belong under the relevant `__tests__/` directory, not as siblings.
- Extract components, hooks, helpers, or abstractions only for reuse, real boundaries, or large bodies.
- Do not add comments to untouched code; delete confirmed-dead code instead of leaving markers.
- Regenerate derived docs from source rather than editing generated docs directly.

## Validation

- Run `vp check --fix` after code or docs source edits when feasible.
- Run `vp test` or a focused `vp test <pattern>` for behavior changes.
- Run `npm run doc` when guides, source docs, API JSDoc, or docs navigation are affected.