01
Build the output before the interface
Start with the pages and metadata that users and crawlers need in initial HTML. Add a browser boundary only when the behavior cannot be expressed as a native document interaction.
- Render meaningful HTML before adding client code.
- Keep normal anchors and forms as the fallback.
- Inspect generated output at every milestone.
02
Separate framework contracts from application ownership
Nexis owns the rendering, routing, resumability, state, Action, metadata, and adapter contracts. Your application owns identity, durable stores, external service credentials, business rules, and operations.
- Never present a framework helper as a hosted database or identity system.
- Keep secrets outside JSX and browser artifacts.
- Write resource authorization in the server operation that owns the resource.
03
Use evidence to move forward
The Workbench project has an explicit typecheck, Action test, budget check, build, and production-output smoke path. Extend those checks with your own provider and data-layer tests before release.
- Record the command, environment, route, and result.
- Test failure paths as deliberately as success paths.
- Keep a deployment and rollback runbook.
pnpm --filter @mohammedaydan/example-nexis-workbench verify
NEXIS_PORT=4174 pnpm --filter @mohammedaydan/example-nexis-workbench startSCOPE BOUNDARY
Do not confuse a pattern with a built-in.
The reference is a framework-contract example, not a hosted database, authentication provider, payment system, or production security approval.
PRACTICE LAB
Prove the behavior.
Read the Workbench route, Action, session-policy, and test files. Then reproduce the sequence in a clean project while replacing only the application-owned integration seams.