CodeVetter · Repo Unpack · Contributor handoff
redwoodjs/redwood
Begin with the owning package and follow the application's configuration, compiler, and runtime boundaries before editing. The repository contains current implementations alongside legacy fixtures and documentation that can describe different development epochs. Tests and CI were inspected, not executed, and this inventory is bounded; future agents must obtain actual check results under appropriate execution authority. Keep changes small and account for generated metadata, browser environment exposure, and interfaces shared across deployment modes.
- Use the root's Yarn 4.6.0 package-manager declaration and existing Nx scripts as the tooling baseline; the empty-project fixture's Node 14–16/Yarn 1 constraints describe that fixture rather than the root.
- For CLI changes, read index.js, the command module, and its handler first; the dev command illustrates lazy handler import and a documented hidden forwarding option.
- For Cell changes, inspect createCell.tsx together with GraphQLHooksProvider-based tests and Apollo defaults, since variables, lifecycle rendering, and cache-and-network behavior cross those boundaries.
- For GraphQL changes, read both createGraphQLHandler and the Fastify GraphQL plugin: Lambda uses yoga.fetch, while the server uses handleNodeRequest and can add realtime plugins.
- Use __fixtures__/test-project/api/src/functions/graphql.ts as the inspected current bootstrap reference; compare older example-todo-main imports before copying them.
- Package export changes need ESM/CommonJS/react-server consideration, and GraphQL test setup contains a deliberate single-module-instance workaround that should not be removed casually.
- Under later execution authorization, start with the owning workspace's existing test script, such as yarn workspace @redwoodjs/cli test or yarn workspace @redwoodjs/graphql-server test; root yarn test is the broader Nx suite.
- Tests and CI were inspected, not executed in this briefing; the active workflow's test-ci, tutorial Cypress, and background-job E2E commands are configured checks, not evidence of successful runs.
- Documentation edits belong in docs/docs rather than generated versioned documentation; the README's separate SDK promotion and aspirational Bighorn section require care when describing implemented capabilities.
- Framework-to-project synchronization is materially stateful: CONTRIBUTING documents rebuilding, copying dependencies, running installation, copying packages, and watching changes, controlled by RWFW_PATH.
- Read Scheduler, PrismaAdapter, Worker, Executor, and loaders before altering jobs: persisted handler JSON, conditional locking, retries, and compiled module paths jointly define the execution contract.
- Avoid exploratory CLI execution during source-only audits: CLI startup loads application environment files and starts telemetry unless disabled, while plugin loading can install packages and write commandCache.json.