This file defines normative development rules for this repository.
All RFC 2119 keywords (MUST, MUST NOT, SHOULD, etc.) are to be interpreted as described in: https://www.rfc-editor.org/rfc/rfc2119.html
- NEVER USE MEMORY CACHE.
- ALWAYS READ CURRENT FILE STATE FROM DISK OR THE ACTIVE CODE EDITOR BUFFER.
- AGENT MEMORY IS A FORBIDDEN STATE / REALITY SOURCE.
- When uncertain about behavior, prefer primary specifications and vendor documentation over assumptions.
- Do not invent behavior. Verify it.
Run the smallest set of checks that covers your change.
- If you change runtime logic or public API:
npm run test. - If you touch benchmarks or performance-sensitive code:
npm run bench. - If you modify TypeScript build config or emit-related logic:
npm run build. - If you change formatting or add files:
npm run format.
If a required command cannot run in the current environment, state that explicitly and explain why.
Every directory under src/ represents a single logical unit.
Each unit:
- MUST contain at most one root-level
.tsfile. - MUST export at most one top-level class OR one top-level function.
- SHOULD remain under ~100 lines of executable logic (imports and type-only declarations excluded).
- The ~100 line budget counts executable statements only and excludes imports, type-only exports, comments, and blank lines.
- MUST have a single, clear responsibility.
If complexity grows:
- Extract a subdirectory.
- Or prefer an external dependency.
Large files are a design failure, not an achievement.
Reimplementation of common infrastructure logic is forbidden.
- Prefer mature, audited packages over ad-hoc boilerplate.
- Do not reimplement encoding, parsing, crypto primitives, validation frameworks, etc.
- Local code MUST focus on domain logic, not infrastructure recreation.
If boilerplate appears repeatedly, dependency evaluation is mandatory.
Dependency evaluation MUST consider maintenance activity within the last 12 months, license compatibility, known security advisories, API stability, and real-world adoption. Record the decision in change notes or the PR description.
If helpers are unavoidable:
- They MUST reside under a
.helpers/directory. - They MUST be minimal and narrowly scoped.
- They MUST NOT evolve into a general-purpose utility framework.
- They MUST NOT contain domain logic.
A growing .helpers/ directory indicates architectural drift.
Domain logic means business rules, policy decisions, and data model validation specific to this package. It excludes encoding/decoding, crypto, serialization, I/O, and generic data plumbing.
Reusable structural types MUST be isolated.
Structure:
.types/
TypeName/
type.ts
Rules:
- Each reusable type gets its own folder.
- The file MUST be named
type.ts. - No executable logic is allowed in
.types/. - Types define contracts, not behavior.
Errors MUST be explicit, semantic, and typed.
Structure:
.errors/
class.ts
Pattern:
export type PackageNameCode = 'SOME_ERROR_CODE' | 'ANOTHER_ERROR_CODE'
export class PackageNameError extends Error {
readonly code: PackageNameCode
constructor(code: PackageNameCode, message?: string) {
const detail = message ?? code
super(`{@scope/package-name} ${detail}`)
this.code = code
this.name = 'PackageNameError'
}
}Rules:
- Error codes MUST be semantic string literals.
- Error codes MUST be SCREAMING_SNAKE_CASE and use short domain prefixes when needed (example:
CRYPTO_INVALID_KEY). - Throwing raw
Erroris forbidden. - Every thrown error MUST map to an explicit error code.
- Error messages MUST include package scope.
Errors are part of the public contract.
- No multi-responsibility modules
- No utility dumping grounds
- No silent boilerplate replication
- No implicit global state
- No hidden cross-layer imports
Architecture must remain explicit and auditable.
Example disallowed: .helpers/ importing from src/domain/*, or .types/ importing from runtime code.
When working on (cwd | root | .)/index.html:
This applies only when index.html exists or a task explicitly asks to create it. Otherwise, do not create or modify it.
Use ReSpec:
- https://respec.org/docs/
- https://github.com/speced/respec
- https://www.w3.org/community/reports/reqs/
- https://respec.org/docs/#using-respec
- ECMA-262 — https://tc39.es/ecma262/
- WHATWG Infra — https://infra.spec.whatwg.org/
- Infra Extension — https://www.w3.org/TR/xmlschema11-2/
- Base64Url — https://base64.guru/standards/base64url
- JSON — https://www.rfc-editor.org/rfc/rfc8259
- URI — https://www.rfc-editor.org/rfc/rfc3986
-
DID Use Cases — https://www.w3.org/TR/did-use-cases/
-
DID Core v1.0 — https://www.w3.org/TR/did-core/
-
DID Core v1.1 — https://www.w3.org/TR/did-1.1/
-
DID Test Suite — https://w3c.github.io/did-test-suite/
-
DID Extensions — https://www.w3.org/TR/did-extensions/
-
VC Data Model v2.0 — https://www.w3.org/TR/vc-data-model-2.0/
-
VC Overview — https://www.w3.org/TR/vc-overview/
-
VC Test Suite — https://w3c.github.io/vc-test-suite/
-
Distributed Ledger Technologies — https://en.wikipedia.org/wiki/Distributed_ledger
- JSON-LD 1.1 — https://www.w3.org/TR/json-ld11/
- JSON-LD API — https://www.w3.org/TR/json-ld11-api/
- RDF Concepts — https://www.w3.org/TR/rdf11-concepts/
- RDF Schema — https://www.w3.org/TR/rdf-schema/
- Schema Org — https://schema.org/docs/schemas.html
- Web Cryptography Level 2 — https://www.w3.org/TR/webcrypto-2/
- JWS — https://www.rfc-editor.org/rfc/rfc7515.html
- JWE — https://www.rfc-editor.org/rfc/rfc7516.html
- JWK — https://www.rfc-editor.org/rfc/rfc7517.html
- JWA — https://www.rfc-editor.org/rfc/rfc7518.html
- JWT — https://www.rfc-editor.org/rfc/rfc7519.html
- JWS Unencoded Payload — https://www.rfc-editor.org/rfc/rfc7797.html
- JWT BCP — https://www.rfc-editor.org/rfc/rfc8725.html
- JWT/JWS Updates — https://www.rfc-editor.org/rfc/rfc9864.html
- JOSE Cookbook — https://www.rfc-editor.org/rfc/rfc7520.html
- JWK Thumbprint — https://www.rfc-editor.org/rfc/rfc7638.html
- EdDSA for JOSE — https://www.rfc-editor.org/rfc/rfc8037.html
- IANA JOSE Registries — https://www.iana.org/assignments/jose/jose.xhtml
- KERI — https://trustoverip.github.io/kswg-keri-specification/
- ACDA — [https://trustoverip.github.io/kswg-acdc-specification/][https://trustoverip.github.io/kswg-acdc-specification/s]
- CESR — https://trustoverip.github.io/kswg-cesr-specification/
Your knowledge of Cloudflare Workers MAY be outdated.
Before any task involving Workers, KV, R2, D1, Durable Objects, Queues, Vectorize, Workers AI, Hyperdrive, or Agents:
- Retrieve current documentation.
- Verify platform limits.
- Confirm API behavior against official docs.
- If documentation cannot be retrieved due to environment restrictions, request permission to browse and state the limitation.
- Workers — https://developers.cloudflare.com/workers/
- Agents — https://developers.cloudflare.com/agents/
- MCP — https://developers.cloudflare.com/agents/model-context-protocol/
Always consult official limits pages before reasoning about quotas.
| Command | Purpose |
|---|---|
npx wrangler dev |
Local development |
npx wrangler deploy |
Deploy to Cloudflare |
npx wrangler types |
Generate TypeScript types |
After modifying bindings in wrangler.toml or wrangler.jsonc, run:
npx wrangler types
Small modules. Explicit contracts. Typed errors. Spec-first reasoning. Dependency over reinvention. No hidden state.
Architecture is a constraint system, not a suggestion.