proteum 2.1.9 → 2.2.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (79) hide show
  1. package/.codex/environments/environment.toml +11 -0
  2. package/AGENTS.md +25 -11
  3. package/README.md +19 -9
  4. package/agents/project/AGENTS.md +165 -120
  5. package/agents/project/CODING_STYLE.md +1 -1
  6. package/agents/project/app-root/AGENTS.md +16 -0
  7. package/agents/project/client/AGENTS.md +5 -5
  8. package/agents/project/client/pages/AGENTS.md +13 -13
  9. package/agents/project/diagnostics.md +19 -10
  10. package/agents/project/optimizations.md +5 -6
  11. package/agents/project/root/AGENTS.md +295 -0
  12. package/agents/project/server/routes/AGENTS.md +2 -2
  13. package/agents/project/server/services/AGENTS.md +4 -2
  14. package/agents/project/tests/AGENTS.md +2 -2
  15. package/cli/app/index.ts +31 -7
  16. package/cli/commands/configure.ts +226 -0
  17. package/cli/commands/dev.ts +0 -2
  18. package/cli/commands/diagnose.ts +33 -1
  19. package/cli/commands/explain.ts +1 -1
  20. package/cli/commands/migrate.ts +51 -0
  21. package/cli/commands/orient.ts +169 -0
  22. package/cli/commands/perf.ts +8 -1
  23. package/cli/commands/verify.ts +1003 -49
  24. package/cli/compiler/artifacts/manifest.ts +4 -4
  25. package/cli/compiler/artifacts/routing.ts +2 -2
  26. package/cli/compiler/artifacts/services.ts +12 -3
  27. package/cli/compiler/client/index.ts +65 -19
  28. package/cli/compiler/common/files/style.ts +47 -2
  29. package/cli/compiler/common/generatedRouteModules.ts +31 -38
  30. package/cli/compiler/common/index.ts +10 -0
  31. package/cli/compiler/common/proteumManifest.ts +1 -0
  32. package/cli/compiler/server/index.ts +34 -9
  33. package/cli/context.ts +6 -1
  34. package/cli/index.ts +7 -8
  35. package/cli/migrate/pageContract.ts +516 -0
  36. package/cli/paths.ts +47 -6
  37. package/cli/presentation/commands.ts +100 -10
  38. package/cli/presentation/devSession.ts +4 -6
  39. package/cli/presentation/help.ts +2 -2
  40. package/cli/presentation/ink.ts +10 -5
  41. package/cli/presentation/welcome.ts +2 -4
  42. package/cli/runtime/commands.ts +94 -1
  43. package/cli/scaffold/index.ts +2 -2
  44. package/cli/scaffold/templates.ts +4 -2
  45. package/cli/utils/agents.ts +273 -58
  46. package/client/dev/profiler/index.tsx +3 -2
  47. package/client/router.ts +10 -2
  48. package/client/services/router/index.tsx +6 -22
  49. package/common/dev/connect.ts +20 -4
  50. package/common/dev/console.ts +7 -0
  51. package/common/dev/contractsDoctor.ts +354 -0
  52. package/common/dev/diagnostics.ts +10 -7
  53. package/common/dev/inspection.ts +830 -38
  54. package/common/dev/performance.ts +19 -5
  55. package/common/dev/profiler.ts +1 -0
  56. package/common/dev/proteumManifest.ts +5 -4
  57. package/common/dev/requestTrace.ts +12 -1
  58. package/common/router/contracts.ts +8 -11
  59. package/common/router/index.ts +2 -2
  60. package/common/router/pageData.ts +72 -0
  61. package/common/router/register.ts +10 -46
  62. package/common/router/response/page.ts +28 -16
  63. package/docs/dev-sessions.md +8 -4
  64. package/docs/diagnostics.md +77 -11
  65. package/docs/migrate-from-2.1.3.md +388 -0
  66. package/docs/request-tracing.md +25 -6
  67. package/package.json +6 -1
  68. package/scripts/update-codex-agents.ts +2 -2
  69. package/server/app/container/console/index.ts +11 -1
  70. package/server/app/container/trace/index.ts +117 -0
  71. package/server/app/devDiagnostics.ts +1 -1
  72. package/server/app/index.ts +5 -1
  73. package/server/services/auth/index.ts +9 -0
  74. package/server/services/router/index.ts +64 -14
  75. package/server/services/router/request/api.ts +7 -1
  76. package/server/services/router/response/index.ts +8 -28
  77. package/types/global/vendors.d.ts +12 -0
  78. package/types/vendors.d.ts +12 -0
  79. package/common/router/pageSetup.ts +0 -51
@@ -3,11 +3,11 @@
3
3
  This is the canonical client-area contract for Proteum-based projects.
4
4
  Role: keep only client-area rules here.
5
5
  Keep here: client component, hook, design-system, accessibility, and client-context usage rules that apply beyond a single page.
6
- Do not put here: page `setup` and route-registration details, server/service rules, or generic project workflow already covered by the project-root `AGENTS.md`.
6
+ Do not put here: page `data` and route-registration details, server/service rules, or generic project workflow already covered by broader ancestor `AGENTS.md` files.
7
7
 
8
- Optimization source of truth: project-root `optimizations.md`.
9
- Diagnostics source of truth: project-root `diagnostics.md`.
10
- Coding style source of truth: project-root `CODING_STYLE.md`.
8
+ Optimization source of truth: root-level `optimizations.md`.
9
+ Diagnostics source of truth: root-level `diagnostics.md`.
10
+ Coding style source of truth: root-level `CODING_STYLE.md`.
11
11
 
12
12
  ## Stack
13
13
 
@@ -39,4 +39,4 @@ Coding style source of truth: project-root `CODING_STYLE.md`.
39
39
  - Keep one component per file.
40
40
  - Load data and define handlers in the directly concerned component when that keeps ownership clearer.
41
41
  - Keep curated lists, option registries, and UI copy catalogs under `/client/catalogs/**`.
42
- - Follow the section-comment format from the project-root `CODING_STYLE.md`.
42
+ - Follow the section-comment format from the root-level `CODING_STYLE.md`.
@@ -2,30 +2,30 @@
2
2
 
3
3
  This is the canonical page-file contract for Proteum-based projects.
4
4
  Role: keep only page-file rules here.
5
- Keep here: `Router.page(...)` registration, SSR `setup` and `render` contracts, page payload shape, and page-local typing rules.
5
+ Keep here: `Router.page(...)` registration, SSR `data` and `render` contracts, page payload shape, and page-local typing rules.
6
6
  Do not put here: generic component rules, server/service implementation details, or app-wide workflow already covered by broader AGENTS files.
7
7
 
8
- Optimization source of truth: project-root `optimizations.md`.
9
- Diagnostics source of truth: project-root `diagnostics.md`.
10
- Coding style source of truth: project-root `CODING_STYLE.md`.
8
+ Optimization source of truth: root-level `optimizations.md`.
9
+ Diagnostics source of truth: root-level `diagnostics.md`.
10
+ Coding style source of truth: root-level `CODING_STYLE.md`.
11
11
 
12
12
  ## Router.page Usage
13
13
 
14
14
  - Proteum scans page files for top-level `Router.page(...)` and `Router.error(...)` calls.
15
15
  - File path controls chunk identity and layout discovery; route path comes from the explicit `Router.page(...)` string.
16
- - Supported page signatures are `Router.page(path, render)`, `Router.page(path, setup, render)`, `Router.page(path, options, render)`, and `Router.page(path, options, setup, render)`.
17
- - Prefer `Router.page(path, setup, render)` for normal SSR pages.
18
- - Use `Router.page(path, options, setup, render)` when a separate route-options object makes the call clearer.
16
+ - The only supported page signature is `Router.page(path, options, data, render)`.
17
+ - `options` is always required and must be an object.
18
+ - `data` is the only nullable argument. Pass `null` when the page does not need SSR data.
19
19
  - Keep the `Router.page(...)` call compact instead of exploding each outer argument onto its own line.
20
20
  - Keep route registration at top level. Do not hide it behind helper abstractions.
21
21
 
22
- ## Setup And Render
22
+ ## Data And Render
23
23
 
24
- - `setup` returns one flat object.
25
- - `_`-prefixed keys like `_auth`, `_layout`, `_static`, and `_redirectLogged` are route options.
26
- - Every other key is SSR data and should be consumed from `render`.
27
- - Controller fetchers and promises returned from `setup` resolve before render.
28
- - If a page needs route data, return it from `setup` and read it in `render`.
24
+ - Route behavior belongs in the explicit `options` object, not in page data.
25
+ - `data` returns one flat object or `null` is passed as the third argument when no page data is needed.
26
+ - Returning route-option keys such as `auth`, `layout`, `static`, `redirectLogged`, or their `_`-prefixed variants from `data` is a contract error.
27
+ - Controller fetchers and promises returned from `data` resolve before render.
28
+ - If a page needs route data, return it from `data` and read it in `render`.
29
29
 
30
30
  ## Page Rules
31
31
 
@@ -4,7 +4,7 @@ This file is the canonical source of truth for diagnostics, temporary instrument
4
4
 
5
5
  ## Initial Triage
6
6
 
7
- - Start with machine-readable app state before reading large parts of the codebase: `./.proteum/manifest.json`, `npx proteum connect --json`, `npx proteum explain --json`, `npx proteum doctor --json`, and `npx proteum doctor --contracts --json` when generated artifacts or manifest-owned files may be stale.
7
+ - Start with machine-readable app state before reading large parts of the codebase: `npx proteum orient <query>`, `./.proteum/manifest.json`, `npx proteum connect --json`, `npx proteum explain --json`, `npx proteum doctor --json`, and `npx proteum doctor --contracts --json` when generated artifacts or manifest-owned files may be stale.
8
8
  - When one app depends on another app's generated controllers, inspect `npx proteum connect --controllers`, `npx proteum explain --connected --controllers`, the producer `proteum.connected.json`, the consumer `proteum.config.ts` connected `source` value, and the producer `./.proteum/proteum.connected.d.ts` before assuming the contract is local.
9
9
  - Use `rg -n` first to narrow the exact code path, then read only the relevant files.
10
10
  - Inspect `./server/index.ts`, `./server/config/*.ts`, and the touched files under `./commands`, `./server/controllers`, `./server/services`, `./server/routes`, `./client/pages`, and `./tests`.
@@ -12,23 +12,28 @@ This file is the canonical source of truth for diagnostics, temporary instrument
12
12
 
13
13
  ## Runtime Diagnostics
14
14
 
15
- - For long-lived dev reproductions, start the app with `npx proteum dev --session-file <path> --replace-existing --port <port>` so the session can be listed and stopped deterministically after the repro.
16
- - Human-facing Proteum CLI runs now print the welcome banner and include the active Proteum installation method, but only `npx proteum dev` clears the interactive terminal before rendering and reports connected app names plus successful connected `/ping` checks in the ready banner; keep that in mind when capturing or comparing command logs during diagnosis.
15
+ - For long-lived dev reproductions, always request elevated permissions and run `npx proteum dev` outside the sandbox. Use an explicit task/thread-scoped session file, inspect `npx proteum dev list --json` plus current listeners first, for example with `lsof -nP -iTCP -sTCP:LISTEN`, then choose a port that is not currently used before starting `npx proteum dev --session-file <path> --port <port>`.
16
+ - Use `--replace-existing` only when restarting the exact session file started by the current thread/task. Never replace another live session that belongs to a user, another thread, or an unknown owner.
17
+ - Only the bare `npx proteum build` and bare `npx proteum dev` commands print the welcome banner and active Proteum installation method. Any extra argument or option skips the banner. Only `npx proteum dev` clears the interactive terminal before rendering and reports connected app names plus successful connected `/ping` checks in the ready banner; keep that in mind when capturing or comparing command logs during diagnosis.
18
+ - For ownership or repo discovery questions, start with `npx proteum orient <query>` instead of jumping straight into source searches.
17
19
  - For request-time issues in dev, start with `npx proteum diagnose <path> --port <port>` when you have a concrete failing route, page, controller path, or request target. It combines owner lookup, manifest diagnostics, contract diagnostics, matching trace data, and buffered server logs in one pass.
20
+ - Prefer focused verification before global checks: `npx proteum verify owner <query>`, `npx proteum verify request <path>`, and only then `npx proteum verify browser <path>` or targeted Playwright when the bug is browser-visible.
21
+ - When diagnosing a consumer app that depends on local `file:` connected projects, boot every connected producer app too, each on its own free port and task-scoped session file, and run every one of those `proteum dev` processes with elevated permissions outside the sandbox before reproducing the consumer issue.
18
22
  - For connected-project failures, confirm the consumer app resolves the expected `connect.<Namespace>.source` and `connect.<Namespace>.urlInternal` values, the producer app exposes `GET /api/__proteum/connected/ping`, and the imported controller entries show `scope=connected` in `proteum explain`.
19
23
  - Use `npx proteum explain owner <query>` when you need a fast ownership graph for a route, controller path, source file, or generated artifact before reading code.
20
- - For performance issues or regressions in dev, use `npx proteum perf top --since <window>` to rank hot paths, `npx proteum perf request <requestId|path>` for one request waterfall, `npx proteum perf compare --baseline <window> --target <window>` for regressions, and `npx proteum perf memory --since <window>` for heap or RSS drift.
24
+ - For performance issues or regressions in dev, use `npx proteum perf top --since <window>` to rank hot paths, `npx proteum perf request <requestId|path>` for one request waterfall plus chain attribution and SQL fingerprints, `npx proteum perf compare --baseline <window> --target <window>` for regressions, and `npx proteum perf memory --since <window>` for heap or RSS drift.
21
25
  - For bundle-size inspection, use `npx proteum build --prod --analyze` to emit `bin/bundle-analysis/client.html` and `client-stats.json`, or add `--analyze-serve --analyze-port auto` when you want a local analyzer URL instead of a static HTML file.
22
26
  - For request-time issues in dev, inspect traces before adding logs when the diagnose surface is still too coarse.
23
27
  - If a server is already running on the default port from `PORT` or `./.proteum/manifest.json`, inspect existing traces before reproducing the issue.
24
28
  - If existing traces are insufficient, arm `npx proteum trace arm --capture deep`, reproduce once, then inspect the new request with `npx proteum trace latest` or `npx proteum trace show <requestId>`.
25
29
  - Inspect browser console errors and warnings for frontend, SSR, hydration, and controller-call issues.
26
30
  - Inspect server startup and runtime errors.
27
- - For protected browser or API flows in dev, prefer `npx proteum session <email> --role <role>` over driving the login UI. Use the login UI only when auth UX itself is under test.
31
+ - For protected browser or API flows in dev, prefer `npx proteum session <email> --role <role>` over driving the login UI. Feed that auth into `npx proteum verify browser ...` or direct Playwright. Use the login UI only when auth UX itself is under test.
28
32
 
29
33
  ## Temporary Instrumentation
30
34
 
31
35
  - When manifest inspection, trace data, browser console output, and server errors are still insufficient, add temporary targeted logs in the code to confirm control flow, payload shape, query shape, or branch selection.
36
+ - If SQL is needed during diagnosis, keep it read-only. Never use SQL to change database structure or execute schema-mutating DDL.
32
37
  - Keep temporary logs narrow, contextual, and easy to remove. Do not leave broad debug noise in shared execution paths.
33
38
  - Re-run only the smallest relevant repro, request, or test after adding temporary instrumentation.
34
39
  - Temporary logs added in the code for diagnosis must be cleaned at the end of tests or the repro cycle and must never be committed.
@@ -36,6 +41,7 @@ This file is the canonical source of truth for diagnostics, temporary instrument
36
41
  ## Error Solving
37
42
 
38
43
  - Fix the contract boundary, not only the downstream symptom.
44
+ - Treat provider, SSR/client-only hook, router-context, and connected-boundary failures as contract mistakes first. The likely fix is where the boundary was crossed incorrectly, not only where the throw surfaced.
39
45
  - Prefer explicit typed schemas, adapters, query `select`s, and narrow response shapes over casts, broad payloads, or hidden fallbacks.
40
46
  - Keep patches narrow, then verify immediately at the failing layer before broadening the test surface.
41
47
  - Review the resulting diff to confirm the fix removed the cause instead of masking it.
@@ -43,13 +49,16 @@ This file is the canonical source of truth for diagnostics, temporary instrument
43
49
  ## Verification And Testing
44
50
 
45
51
  - Use the cheapest trustworthy verification that matches the failing layer.
46
- - After implementing a feature or behavior change, always verify it on a running app instead of stopping at static analysis or code review.
47
- - For compile-time or type-safety issues, start with the relevant typecheck or build command.
52
+ - After implementing a change, verify only at the smallest trustworthy layer required by the changed surface. Do not default to a running app, project-wide typecheck, `npx proteum check`, or Playwright when a narrower static or request-level verification is enough.
53
+ - For compile-time or type-safety issues, start with the relevant targeted typecheck or build command. Do not run them by default for unrelated runtime, copy, docs, or local refactor changes.
48
54
  - For request/runtime issues, verify through the real page, route, generated controller call, or command on a running app.
49
- - Start the smallest trustworthy runtime surface first: boot the server, run the relevant real URL, generated controller call, command, or `npx proteum diagnose <path> --port <port>`, then add targeted Playwright coverage when the change is browser-visible.
50
- - For browser regressions, prefer targeted Playwright coverage and inspect failure artifacts such as screenshots, videos, `error-context.md`, and Playwright traces.
55
+ - Start the smallest trustworthy runtime surface first: `npx proteum orient <query>`, then the relevant real URL, generated controller call, command, or `npx proteum diagnose <path> --port <port>`. Add targeted Playwright coverage only when request-level verification is insufficient or the change is browser-visible.
56
+ - Proteum does not provide a dedicated raw browser-runtime CLI. When `npx proteum verify browser` is insufficient, use direct Playwright with a disposable profile. Do not launch raw browser automation against a shared persistent profile.
57
+ - Focused verification should treat unrelated global diagnostics as visible but non-blocking by default. Use `--strict-global` only when the task explicitly requires broad clean-room validation.
58
+ - For browser regressions, prefer a real browser repro first and add targeted Playwright coverage only when the user asks for automated coverage, when a stable regression path needs automation, or when manual/browser verification is insufficient.
59
+ - Only the final verifier agent should usually run browser flows. Earlier agents should stay on `orient`, `verify owner`, `verify request`, `diagnose`, and command-level checks unless browser execution is the only trustworthy reproducer.
51
60
  - Treat server startup failures, runtime errors, browser console errors or warnings, and Playwright failures as blocking unless they are clearly unrelated to the change.
52
- - When the touched surface can affect coding-style enforcement, run the smallest relevant project check such as `npx proteum lint` or `npx proteum check` before finishing.
61
+ - When the touched surface can affect coding-style enforcement, run the smallest relevant static check. Do not default to `npx proteum check`; prefer a narrower lint or type check only when the changed surface or an observed issue calls for it.
53
62
  - If the task started any long-lived `proteum dev` server, stop it explicitly with `npx proteum dev stop --session-file <path>` or `npx proteum dev stop --all --stale`, then confirm the remaining tracked sessions with `npx proteum dev list --json`.
54
63
  - Add `data-testid` when stable selectors are missing instead of relying on brittle text or DOM-shape selectors.
55
64
  - If an isolated test misses prerequisite state, run the smallest broader scope that reproduces the real setup.
@@ -22,12 +22,11 @@ When tradeoffs exist inside optimization work, optimize in this order:
22
22
 
23
23
  ## SSR And Page Size
24
24
 
25
- - SSR page data belongs in page `setup`, not in `api.fetch(...)`.
26
- - Prefer `Router.page(path, setup, render)` for normal SSR pages.
27
- - `setup` returns one flat object.
28
- - `_`-prefixed keys are route options. Every other key is SSR data and should be consumed from `render`.
29
- - If a page needs route data, return it from `setup` and read it in `render`.
30
- - Controller fetchers and promises returned from `setup` resolve before render.
25
+ - SSR page data belongs in the explicit `Router.page(path, options, data, render)` `data` function, not in `api.fetch(...)`.
26
+ - `options` carries route behavior. `data` returns one flat object or is `null` when the page has no SSR data loader.
27
+ - Route-option keys and `_`-prefixed route-option aliases are forbidden in page data and must live in `options`.
28
+ - If a page needs route data, return it from `data` and read it in `render`.
29
+ - Controller fetchers and promises returned from `data` resolve before render.
31
30
  - Never use `api.fetch(...)` in page files for SSR loading.
32
31
  - Synchronous or SSR data calls must return only the strictly necessary data for the current render path to minimize SSR payload size.
33
32
  - If an existing controller or data method returns a broader shape than the SSR path needs, create a dedicated proxy controller method with a narrower typed contract instead of reusing the oversized payload.
@@ -0,0 +1,295 @@
1
+ # Proteum Root Contract
2
+
3
+ This is the reusable Proteum-wide contract that is safe to place at the root of a monorepo above one or more Proteum apps.
4
+ Pair this file with an app-root `AGENTS.md` inside each Proteum app when local workflow or product-context instructions depend on the current directory being the app root.
5
+ Role: keep only reusable Proteum workflow, architecture contracts, shared typing rules, and cross-surface verification rules here.
6
+ Do not put here: app-root bootstrap steps, local product-doc reading rules, detailed diagnostics workflow, optimization checklists, coding-style details, or narrow area-specific instructions that belong in `diagnostics.md`, `optimizations.md`, `CODING_STYLE.md`, `client/AGENTS.md`, `client/pages/AGENTS.md`, `server/routes/AGENTS.md`, `server/services/AGENTS.md`, or `tests/AGENTS.md`.
7
+
8
+ Optimization source of truth: root-level `optimizations.md`.
9
+ Diagnostics source of truth: root-level `diagnostics.md`.
10
+ Coding style source of truth: root-level `CODING_STYLE.md`.
11
+
12
+ ## Fast Triggers
13
+
14
+ - If the user pastes raw errors without asking for a fix, do not implement changes. List likely causes and, for each one, give probability, why, and how to fix it.
15
+ - If the task is ambiguous, generated, connected, or multi-repo, start with `npx proteum orient <query>` before reading large parts of the codebase.
16
+ - If the user reports an issue, or the agent encounters one during exploration, implementation, verification, or runtime reproduction, load and follow root-level `diagnostics.md`.
17
+ - If the task touches client-side files, especially `client/**` and page files, load and apply root-level `optimizations.md` only after implementation for post-implementation checking and optimization. Skip it at task start and skip it for server-only, test-only, doc-only, and non-client refactor tasks unless the user explicitly asks for optimization work.
18
+ - If the task needs new app or artifact boilerplate, prefer `npx proteum init ...` and `npx proteum create ...` before creating files by hand. Use `--dry-run --json` when an agent needs a machine-readable plan before writing files.
19
+ - If you changed `schema.prisma`, do not start testing or validation yet. Ask the user to run the following command in the affected worktree directory, replacing the placeholders, and wait for the user to reply exactly `continue` before resuming validation or tests:
20
+ ```
21
+ cd <worktree path>
22
+ npx prisma migrate dev --config ./prisma.config.ts --name <migration name>
23
+ ```
24
+ - If you encounter `runtime/provider-hook-outside-provider`, `runtime/client-only-hook-in-ssr`, `runtime/router-context-outside-router`, or `runtime/connected-boundary-mismatch`, treat it as a framework contract failure first. Fix the provider, SSR/client, router, or connected boundary before assuming a local leaf-component bug.
25
+ - If the change is runtime-visible, request-time, router, SSR, browser-visible, or controller-behavior, use running-app verification.
26
+ - If the change is docs-only, wording-only, type-only, test-only, generated-output cleanup, or a clearly local non-runtime refactor, use static verification only unless the user explicitly asks for runtime verification or the agent finds a real issue.
27
+ - If the user replies exactly `commit`, generate one top-level short (up to 100 characters) sentence covering all changes made since the last `commit` and, if there has been no prior `commit`, since the beginning of the whole conversation, strictly using the Conventional Commits specification:
28
+ ```
29
+ <type>[optional scope]: <description>
30
+
31
+ [optional body]
32
+ ```
33
+ Then use that generated message, stage the task-related changed files with `git add` while avoiding unrelated user changes or incidental untracked files, and create the commit by running `git commit`. Do not stop at only suggesting the message.
34
+ After providing a commit message or after creating a commit, immediately follow it with this exact prompt and obey it:
35
+ `Explain in short minimalistic and few bullet points what we changed in this thread, like you would do to your grandma. Start with a verb in the past.`
36
+
37
+ ## Task Lifecycle
38
+
39
+ ### Before Editing
40
+
41
+ - Before changing any file, load root-level `CODING_STYLE.md` and any narrower area `AGENTS.md` that applies to the touched files. Do not spend response space explicitly acknowledging those reads unless the user asks.
42
+
43
+ ### During Implementation
44
+
45
+ - After running `npx proteum create ...`, adapt the generated code to the real feature instead of leaving placeholder logic in place.
46
+ - When starting a long-lived dev server for an agent task, always request elevated permissions and run `npx proteum dev` outside the sandbox. Use an explicit task/thread-scoped session file such as `var/run/proteum/dev/agents/<task>.json`, inspect `npx proteum dev list --json` plus current listeners first, for example with `lsof -nP -iTCP -sTCP:LISTEN`, then choose a port that is not currently used before starting `npx proteum dev --session-file <path> --port <port>`.
47
+ - Use `--replace-existing` only when restarting the exact session file started by the current thread/task. Never replace another live session that belongs to a user, another thread, or an unknown owner.
48
+ - If the current app depends on local `file:` connected projects, boot every connected producer app too, each with its own task-scoped session file and free port, and run every one of those `proteum dev` processes with elevated permissions outside the sandbox before starting or verifying the consumer app.
49
+ - For raw browser automation, use `npx proteum verify browser` when it matches the task, or direct Playwright with a disposable profile when lower-level control is required. Bootstrap protected browser state through `npx proteum session`.
50
+ - Current CLI banner contract: only the bare `proteum build` and bare `proteum dev` commands print the welcome banner and include the active Proteum installation method. Any extra argument or option skips the banner. Only `proteum dev` clears the interactive terminal before rendering, exposes `CTRL+R` reload plus `CTRL+C` shutdown hotkeys in its session UI, and reports connected app names plus successful connected `/ping` checks in the ready banner.
51
+
52
+ ### Before Finishing
53
+
54
+ - Before finishing, re-check touched files against root-level `CODING_STYLE.md` and any narrower area `AGENTS.md` that applied to the edit. Re-check against root-level `optimizations.md` only for touched client-side files. Re-check against root-level `diagnostics.md` only if the task involved an issue, diagnosis, runtime reproduction, or verification failure.
55
+ - Do not default to project-wide typecheck, `npx proteum check`, or Playwright after every change. Run them only when the user asks for them, when the changed surface specifically requires them, or when a real issue discovered during verification justifies escalation.
56
+ - Before finishing a task, stop every `proteum dev` session started during the task and confirm cleanup with `npx proteum dev list --json` or an explicit `npx proteum dev stop --session-file <path>`.
57
+ - When you have finished your work, ask the user whether they want a commit message. After providing a commit message or after creating a commit, immediately follow it with this exact prompt and obey it:
58
+ `Explain in short minimalistic and few bullet points what we changed in this thread, like you would do to your grandma. Start with a verb in the past.`
59
+
60
+ ## Core Contracts
61
+
62
+ - Client pages live in `client/pages/**` and register routes with top-level `Router.page(...)` or `Router.error(...)`.
63
+ - Page URLs come from the explicit `Router.page('/path', ...)` call, not from the file path.
64
+ - Callable app APIs live only in `server/controllers/**/*.ts` files that extend `Controller`.
65
+ - Dev-only internal execution lives only in `commands/**/*.ts` files that extend `Commands`.
66
+ - Manual HTTP endpoints live only in `server/routes/**`.
67
+ - Controllers call `this.input(schema)` inside the method body, at most once per method.
68
+ - Request-scoped state lives only on `this.request` and manual-route/router context objects.
69
+ - Keep one class or one React/Preact component per file.
70
+ - Prefer a deep tree grouped by business concern instead of long file names.
71
+ - Use the default `*.ts` or `*.tsx` file unless an `*.ssr.ts` or `*.ssr.tsx` variant is truly required.
72
+ - Never edit generated files under `.proteum`.
73
+ - When a task changes database structure, edit the app's `schema.prisma` only.
74
+ - Never create or edit migration files manually.
75
+ - Use `@generated/client/*`, `@generated/common/*`, and `@generated/server/*` for generated surfaces.
76
+ - Client context is typically imported from `@/client/context`.
77
+ - Normal service methods do not read request state directly.
78
+ - Do not import runtime values from `@models`.
79
+ - Do not use `@request` runtime globals.
80
+ - Do not use `@app` on the client.
81
+ - Prefer type inference rooted in the explicit application graph in `server/index.ts`.
82
+
83
+ ## Surface Contracts
84
+
85
+ ### App Bootstrap And Services
86
+
87
+ - `server/index.ts` default-exports the app `Application` subclass and is the canonical type root.
88
+ - Root services are public class fields instantiated with `new ServiceClass(this, config, this)`.
89
+ - Typed root-service config lives in `server/config/*.ts` via `Services.config(ServiceClass, { ... })`.
90
+ - Router plugins are instantiated explicitly inside the `Router` config `plugins` object.
91
+ - Root business services live in `server/services/<Feature>/index.ts`.
92
+ - Root-service config lives in `server/config/*.ts` when the service needs config.
93
+ - Business logic lives in classes that extend `Service` and use `this.services`, `this.models`, and `this.app`.
94
+ - Keep auth, input parsing, locale, cookies, and request-derived values in controllers, then pass explicit typed arguments into services.
95
+ - Split growing features into explicit subservices.
96
+ - Companion client-callable entrypoints live in `server/controllers/**`.
97
+ - `proteum create service ...` scaffolds the service file, a typed config export under `server/config/*.ts`, and the root registration in `server/index.ts`; review and adapt the generated names before committing.
98
+
99
+ ### Connected Projects
100
+
101
+ - Declare connected namespaces in `proteum.config.ts` with explicit values such as `connect: { Product: { source: PRODUCT_CONNECTED_SOURCE, urlInternal: PRODUCT_URL_INTERNAL } }`.
102
+ - Proteum does not infer connected env key names from the namespace. The source and internal URL must be provided explicitly in `proteum.config.ts`.
103
+ - Use `npx proteum connect` to inspect configured connect values, cached contract state, and imported controllers for the current app.
104
+ - Before launching a consumer app that depends on local `file:` connected sources, launch every connected producer app too, assign each one a free port, run each `proteum dev` outside the sandbox with elevated permissions, and make sure `connect.<Namespace>.urlInternal` resolves to those live producer URLs.
105
+ - `file:` connected sources point at another Proteum app root and keep strong connected typings.
106
+ - Non-local connected sources provide runtime helper generation but are intentionally typed loosely.
107
+
108
+ ### Controllers
109
+
110
+ - Files live under `server/controllers/**/*.ts` and default-export a class extending `Controller`.
111
+ - Methods with bodies become generated client-callable endpoints.
112
+ - Route path comes from the controller file path plus the method name.
113
+ - `export const controllerPath = 'Custom/path'` can override the base path.
114
+ - Generated client calls use `POST`.
115
+ - Prefer `proteum create controller ...` for new controller boilerplate, then adapt the generated method to real service calls.
116
+
117
+ ### Commands
118
+
119
+ - Files live under `commands/**/*.ts` and default-export a class extending `Commands` from `@server/app/commands`.
120
+ - Methods with bodies become generated dev commands.
121
+ - Command path comes from the file path plus the method name.
122
+ - `export const commandPath = 'Custom/path'` can override the base path.
123
+ - Commands are for dev-only internal execution through `proteum command ...` or the profiler `Commands` tab.
124
+ - Keep command logic internal; do not turn it into a normal controller unless it is a real app API.
125
+ - Prefer `proteum create command ...` for new command boilerplate.
126
+
127
+ ### Client Pages
128
+
129
+ - Proteum scans page files for top-level `Router.page(...)` and `Router.error(...)` calls.
130
+ - File path controls chunk identity and layout discovery; route path comes from the explicit `Router.page(...)` string.
131
+ - The only supported page signature is `Router.page(path, options, data, render)`.
132
+ - `options` is always required. `data` is the only nullable argument and must be `null` when the page has no SSR data loader.
133
+ - `data` returns one flat object. Route-option keys such as `auth`, `layout`, `static`, and `_static` are forbidden in page data and must live in `options`.
134
+ - Controller fetchers and promises returned from `data` resolve before render.
135
+ - `render` consumes resolved page data and uses generated controller methods from render args or `@/client/context`.
136
+ - Use `api.reload(...)` or `api.set(...)` only when intentionally mutating active page data state.
137
+ - Error pages use `Router.error(code, options, render)` in `client/pages/_messages/**`.
138
+ - Prefer `proteum create page ...` for new page boilerplate, then review the explicit route path, options object, and data payload.
139
+
140
+ ### Manual Routes
141
+
142
+ - Use `server/routes/**` only for explicit HTTP behavior that should not be a generated controller action.
143
+ - Good fits include redirects, sitemap or RSS output, OAuth callbacks, webhooks, and public resources with custom semantics.
144
+ - Import server-side app services from `@app` and use route handler context for `request`, `response`, router plugins, and custom router context.
145
+ - If the route is a normal app API, prefer a controller.
146
+ - Prefer `proteum create route ...` for new manual-route boilerplate.
147
+
148
+ ### Models And Aliases
149
+
150
+ - Use Prisma typings from `@models/types`.
151
+ - Use runtime models through `this.models` or `this.app.Models.client`.
152
+ - Keep Prisma runtime access inside services when possible and prefer explicit `select` or narrow `include`.
153
+ - Do not import runtime values from `@models` or edit generated Prisma client files.
154
+ - Aliases:
155
+ - `@/client/...`, `@/server/...`, `@/common/...`: app code
156
+ - `@client/...`, `@server/...`, `@common/...`: Proteum core modules
157
+ - `@app`: server-side application services for manual routes only
158
+ - `@generated/*`: generated app surfaces
159
+
160
+ ## Verification Matrix
161
+
162
+ Verify at the correct layer:
163
+
164
+ - Default: use the cheapest trustworthy verification for the changed surface first, then escalate only if the changed surface justifies it.
165
+ - Route additions: boot the app and hit the real URL.
166
+ - Controller changes: exercise the generated client call or generated `/api/...` endpoint.
167
+ - SSR changes: load the real page and inspect rendered HTML plus browser console.
168
+ - Router or plugin changes: verify request context, auth, redirects, metrics, and validation on a running app.
169
+ - Generated, connected, or ownership-ambiguous changes: start with `npx proteum orient <query>` and prefer `npx proteum verify owner <query>` before broad global checks.
170
+ - Browser-visible issues: prefer `npx proteum verify browser <path>` or the narrowest targeted Playwright pass only after request-level verification is insufficient.
171
+ - Raw browser execution beyond `npx proteum verify browser`: use direct Playwright with a disposable profile, and keep that step for the final verifier agent unless a narrower surface cannot reproduce the issue.
172
+ - For trace-first reproduction, session-based auth setup, temporary logs, and post-fix surface checks, follow root-level `diagnostics.md`.
173
+
174
+ ## Implementation Rules
175
+
176
+ ### Dependency Selection
177
+
178
+ - Before implementing a feature or change, first check whether the repo already includes a suitable dependency.
179
+ - If not, search npm before building a new utility, abstraction, component primitive, parser, formatter, or integration from scratch.
180
+ - Prefer the most popular, flexible, maintained packages that fit the project constraints.
181
+ - When the task explicitly involves client-side optimization work, use root-level `optimizations.md` to decide whether custom infrastructure is justified over an existing package.
182
+ - When you choose custom over a package, explain the reason briefly.
183
+
184
+ ### Catalogs And Typing
185
+
186
+ - Keep one canonical catalog or registry file and import it everywhere else.
187
+ - Client-only catalogs live in `/client/catalogs/**`, server-only catalogs in `/server/catalogs/**`, and shared catalogs in `/common/catalogs/**`.
188
+ - Do not create nested `catalogs/` folders under pages, components, services, tests, or other feature folders.
189
+ - Keep strong TypeScript typings across the project.
190
+ - Do not introduce `any` or `unknown`, including through casts, helper aliases, or fallback generic defaults.
191
+ - Fix typing issues only on code you wrote.
192
+ - Never cast with `as any` or `as unknown`; fix the contract or add an explicit typed adapter.
193
+
194
+ ### Design Rules
195
+
196
+ - Prefer explicit `server/index.ts` bootstrap over hidden registration.
197
+ - Prefer controller-backed app APIs over ad hoc manual `/api/...` routes.
198
+ - Prefer service classes over server helpers with hidden dependencies.
199
+ - Keep one canonical source of truth for catalogs, registries, and shared types.
200
+ - Reuse shared Shadcn-based UI primitives when the project already provides them.
201
+
202
+ ### Discouraged Patterns
203
+
204
+ - request-scoped state inside normal service methods
205
+ - hiding route registration behind abstractions that remove the top-level `Router.page(...)` call
206
+ - editing `.proteum` directly
207
+
208
+ ## Hard Stops
209
+
210
+ - Never run schema-mutating SQL such as `ALTER TABLE`, `CREATE TABLE`, `DROP TABLE`, or `CREATE INDEX` to change database structure.
211
+ - Do not run `prisma *` yourself. If a schema change requires migration, ask the user to run `npx prisma migrate dev --config ./prisma.config.ts --name <migration name>` and wait for `continue`.
212
+ - Do not run `git restore` or `git reset`.
213
+ - Do not run write-mode git commands by default. The built-in exception is an exact `commit` reply, which allows only task-scoped `git add` and `git commit`. Any other write-mode git action requires an explicit user request.
214
+
215
+ ## Appendix
216
+
217
+ ### Project Shape
218
+
219
+ This is a TypeScript, Node.js, Preact, Proteum monolith:
220
+
221
+ - `/client`: assets, catalogs, components, hooks, pages
222
+ - `/common`: shared functions, constants, types, and catalogs
223
+ - `/server`: catalogs, config, services, routes, lib
224
+ - `/tests`
225
+
226
+ ### Source Of Truth
227
+
228
+ Proteum reads:
229
+
230
+ - `package.json`
231
+ - `identity.config.ts` for app identity via `Application.identity({ ... })`
232
+ - `proteum.config.ts` for compiler setup via `Application.setup({ transpile, connect })`
233
+ - `process.env` via `PORT`, `ENV_*`, `URL`, `URL_INTERNAL`, any app-chosen connected-project values referenced by `proteum.config.ts`, and `TRACE_*`
234
+ - `server/config/*.ts`
235
+ - `server/index.ts`
236
+ - `commands/**/*.ts`
237
+ - `server/controllers/**/*.ts`
238
+ - `server/routes/**/*.ts`
239
+ - `client/pages/**/*.ts(x)`
240
+ - `client/pages/**/_layout/index.tsx`
241
+ - `public/**`
242
+
243
+ Proteum owns:
244
+
245
+ - `.proteum/manifest.json`
246
+ - `.proteum/client/*`
247
+ - `.proteum/common/*`
248
+ - `.proteum/server/*`
249
+
250
+ Project code should consume:
251
+
252
+ - `@generated/client/*`
253
+ - `@generated/common/*`
254
+ - `@generated/server/*`
255
+ - `@/client/context` as the generated client context entrypoint
256
+
257
+ ### Useful Commands
258
+
259
+ Prefer structured CLI surfaces over re-deriving framework facts from source:
260
+
261
+ - `npx proteum connect --json`
262
+ - `npx proteum connect --controllers --strict`
263
+ - `npx proteum orient <query>`
264
+ - `npx proteum explain --json`
265
+ - `npx proteum explain --connected --controllers`
266
+ - `npx proteum explain owner <query>`
267
+ - `npx proteum doctor --json`
268
+ - `npx proteum doctor --contracts --json`
269
+ - `npx proteum diagnose <path> --port <port>`
270
+ - `npx proteum verify owner <query>`
271
+ - `npx proteum verify request <path>`
272
+ - `npx proteum verify browser <path>`
273
+ - `npx proteum perf ...`
274
+ - `npx proteum trace ...`
275
+ - `npx proteum command ...`
276
+ - `npx proteum session ...`
277
+ - `npx proteum create ... --dry-run --json`
278
+ - `npx proteum dev list --json`
279
+ - `npx proteum dev stop --session-file <path>`
280
+
281
+ Prefer scaffold commands before hand-writing boilerplate:
282
+
283
+ - `npx proteum init <directory> --name <name>`
284
+ - `npx proteum init ... --dry-run --json`
285
+ - `npx proteum create page|controller|command|route|service <target>`
286
+ - `npx proteum create ... --dry-run --json`
287
+
288
+ ### High-Impact Files
289
+
290
+ Edit these only when required, and keep changes minimal and explicit:
291
+
292
+ - `tsconfig*.json`
293
+ - `PORT`, `ENV_*`, `URL`, and `TRACE_*` env setup
294
+ - Prisma-generated files
295
+ - symbolic links
@@ -5,8 +5,8 @@ Role: keep only manual-route rules here.
5
5
  Keep here: explicit HTTP route guidance, public/crawlable endpoint rules, absolute URL generation, and route-specific catalog placement.
6
6
  Do not put here: controller contracts, service-layer business logic, page SSR rules, or broad project workflow already defined elsewhere.
7
7
 
8
- Optimization source of truth: project-root `optimizations.md`.
9
- Diagnostics source of truth: project-root `diagnostics.md`.
8
+ Optimization source of truth: root-level `optimizations.md`.
9
+ Diagnostics source of truth: root-level `diagnostics.md`.
10
10
 
11
11
  - Use `server/routes/**` only for explicit HTTP behavior that should not be generated from controllers.
12
12
  - If the endpoint is a normal app API, prefer `server/controllers/**/*.ts`.
@@ -5,8 +5,8 @@ Role: keep only service-layer rules here.
5
5
  Keep here: service placement, service responsibilities, model access, query-shaping, return-type guidance, and service error-handling rules.
6
6
  Do not put here: request parsing, page/render rules, controller transport details, or broad project workflow already defined in higher-level AGENTS files.
7
7
 
8
- Optimization source of truth: project-root `optimizations.md`.
9
- Diagnostics source of truth: project-root `diagnostics.md`.
8
+ Optimization source of truth: root-level `optimizations.md`.
9
+ Diagnostics source of truth: root-level `diagnostics.md`.
10
10
 
11
11
  ## Placement
12
12
 
@@ -29,6 +29,8 @@ Diagnostics source of truth: project-root `diagnostics.md`.
29
29
  - Use runtime models through `this.models` or the app model accessors.
30
30
  - Use Prisma typings through `@models/types` only.
31
31
  - In database queries, prefer explicit `select` or narrow `include`.
32
+ - For database structure changes, edit the app's `schema.prisma` only. Never create or edit migration files manually.
33
+ - Never use raw SQL DDL or other schema-mutating SQL to change database structure.
32
34
  - Prefer inferred return types such as `Awaited<ReturnType<MyService['methodName']>>` over manual DTO duplication.
33
35
 
34
36
  ## Errors
@@ -5,12 +5,12 @@ Role: keep only test-area rules here.
5
5
  Keep here: runtime verification guidance, selector strategy, test-specific reuse rules, and authenticated test-flow expectations.
6
6
  Do not put here: production implementation rules, page/service architecture contracts, or duplicated project workflow that belongs in broader AGENTS files.
7
7
 
8
- Diagnostics source of truth: project-root `diagnostics.md`.
8
+ Diagnostics source of truth: root-level `diagnostics.md`.
9
9
 
10
10
  - Understand the real user flow and the main feature branches before writing tests.
11
11
  - Test the current controller/page runtime model, not legacy `@Route` or `api.fetch(...)` behavior.
12
12
  - Verify routing, controllers, SSR, and router plugins against a running app when behavior depends on real request handling.
13
- - After implementing a browser-visible feature or change, run targeted Playwright coverage or a real browser repro against a running app before finishing; this verification is required, not optional cleanup.
13
+ - After implementing a browser-visible feature or change, prefer a real browser repro against a running app first. Add targeted Playwright coverage only when the user asks for automated coverage, when a stable regression path needs automation, or when manual/browser verification is insufficient.
14
14
  - Exercise real URLs, generated controller calls, or real browser flows instead of re-deriving framework internals in tests.
15
15
  - Locate elements with `data-testid`.
16
16
  - Add `data-testid` where needed instead of relying on brittle selectors.
package/cli/app/index.ts CHANGED
@@ -38,20 +38,34 @@ const normalizeModulePath = (value: string) => value.replace(/\\/g, '/').replace
38
38
 
39
39
  const resolveTranspileModuleDirectories = ({
40
40
  moduleNames,
41
- nodeModulesRoots,
41
+ resolvePackageRoot,
42
+ getVisiblePackageInstallRoots,
42
43
  }: {
43
44
  moduleNames: string[];
44
- nodeModulesRoots: string[];
45
+ resolvePackageRoot: (moduleName: string) => string;
46
+ getVisiblePackageInstallRoots: (moduleName: string) => string[];
45
47
  }) => {
46
48
  const directories = new Set<string>();
47
49
 
48
50
  for (const moduleName of moduleNames) {
49
- for (const nodeModulesRoot of nodeModulesRoots) {
50
- const candidate = normalizeModulePath(path.join(nodeModulesRoot, moduleName));
51
+ const candidates = new Set<string>();
52
+
53
+ try {
54
+ candidates.add(normalizeModulePath(resolvePackageRoot(moduleName)));
55
+ } catch {}
56
+
57
+ for (const visibleInstallRoot of getVisiblePackageInstallRoots(moduleName)) {
58
+ candidates.add(normalizeModulePath(visibleInstallRoot));
59
+ }
60
+
61
+ for (const candidate of candidates) {
51
62
  if (!fs.existsSync(candidate)) continue;
52
63
 
53
64
  directories.add(candidate);
54
- directories.add(normalizeModulePath(fs.realpathSync(candidate)));
65
+
66
+ try {
67
+ directories.add(normalizeModulePath(fs.realpathSync(candidate)));
68
+ } catch {}
55
69
  }
56
70
  }
57
71
 
@@ -136,15 +150,25 @@ export class App {
136
150
  public get transpileModuleDirectories() {
137
151
  return resolveTranspileModuleDirectories({
138
152
  moduleNames: this.transpile,
139
- nodeModulesRoots: [cli.paths.framework.appNodeModulesRoot, cli.paths.framework.frameworkNodeModulesRoot],
153
+ resolvePackageRoot: (moduleName) => cli.paths.resolvePackageRoot(moduleName),
154
+ getVisiblePackageInstallRoots: (moduleName) => cli.paths.getVisiblePackageInstallRoots(moduleName),
140
155
  });
141
156
  }
142
157
 
143
158
  public isTranspileModuleFile(filepath: string) {
144
159
  const normalizedFilepath = normalizeModulePath(path.resolve(filepath));
160
+ let normalizedRealFilepath: string | undefined;
161
+
162
+ try {
163
+ normalizedRealFilepath = normalizeModulePath(fs.realpathSync(filepath));
164
+ } catch {}
145
165
 
146
166
  return this.transpileModuleDirectories.some(
147
- (directory) => normalizedFilepath === directory || normalizedFilepath.startsWith(directory + '/'),
167
+ (directory) =>
168
+ normalizedFilepath === directory ||
169
+ normalizedFilepath.startsWith(directory + '/') ||
170
+ normalizedRealFilepath === directory ||
171
+ normalizedRealFilepath?.startsWith(directory + '/') === true,
148
172
  );
149
173
  }
150
174