Code and product audit

Audit date: 2026-07-25

This document records what was inspected, what changed, and what remains intentionally out of scope. It is evidence for maintainers, not a claim that any framework can make every application correct automatically.

#Scope

The audit covered:

• reactive ownership, computed invalidation, DOM updates, SSR, and hydration;
• TSX public typing and event/control ergonomics;
• runtime schemas and agent contracts;
• form state, validation, submission, focus, and cancellation;
• accessible disclosure, dialog, tabs, pagination, and directives;
• semantic agent inspection and operation;
• auth, passkeys, organization RBAC, data ownership, requests, files, deployment artifacts, migrations, secrets, ingress, backup, and release supervision;
• examples, strict types, package contents, documentation, desktop rendering, and narrow viewports.

#Findings resolved

#Readability decisions

• New behavior is split into focused forms.ts and ui.ts modules.
• Public controllers are headless and return ordinary props.
• Runtime schemas remain the source for TypeScript and agent contracts.
• IDs are deterministic for SSR, hydration, accessibility, and agent operation.
• Unsafe or unknown form keys throw rather than fail silently.
• Examples use domain-specific names and semantic native HTML.

Large existing modules such as backend.ts, auth.ts, and platform.ts remain cohesive but substantial. Splitting them without changing their public boundaries is future maintainability work; a mechanical split was not treated as inherently safer than tested cohesive code.

#Security posture

The existing security boundaries remain:

• bounded request and artifact intake;
• executable URL and inline-handler rejection;
• safe SSR escaping and serialized state;
• scrypt password hashing, CSRF, secure cookies, rate limits, roles, and revocation;
• owned SQLite rows and auth-partitioned live queries;
• traversal/symlink defenses;
• encrypted deployment secrets;
• immutable migration history, backup, health-gated activation, and rollback.

The audit added semantic password/file redaction and stricter form-key handling. Client forms and hidden UI are never authorization boundaries.

The 0.7.0 rename also preserves existing accounts, sessions, application rows, migration history, projects, releases, secrets, logs, and audit records. Clank writes only the new names after migration. See Renaming from Proact.

#Application coverage

The current examples prove different mechanics:

• hello: reactive primitives and agent actions.
• todo: keyed client CRUD.
• fullstack: SSR, SQLite, RPC, and live synchronization.
• auth-todo: sessions, user-owned data, SSR, and multi-tab live updates.
• commerce: search/filter/sort, cart state, modal checkout, validation, and async confirmation.
• dashboard: tabs, metrics, responsive navigation, tables, filtering, pagination, invite dialog, and settings.
• booking: multi-step composition, cross-field dates, room selection, computed pricing, guest validation, and confirmation.

These examples demonstrate framework breadth. They do not replace domain-specific payment, tax, inventory, medical, legal, or regulatory integrations.

#Known limits

• Form paths are intentionally top-level. Compose controllers for nested editors and independent wizard steps.
• A capability-gated local file store and upload endpoint are included for trusted single-host deployments; production object storage, CDN delivery, and image transformation remain provider integrations.
• No virtualized list is included yet; large datasets should page server-side.
• Dialogs are rendered in place rather than through a portal.
• The built-in process supervisor remains single-leader even though durable distributed coordination primitives are available.
• The trusted process runner is not a sandbox; use the Docker runner for stronger isolation.
• Clank now provides verified domain eligibility for Caddy On-Demand TLS, but certificate/key custody, WAF/DDoS service, WebSocket ingress, remote worker integration, and globally distributed control storage remain external or future platform work.
• Tailwind's browser build is suitable for examples and zero-install prototyping; production applications should serve compiled CSS.

#Release gate

A release is acceptable only after:

1. the zero-dependency TS/TSX syntax-lowering build succeeds;
2. checked-in declarations match built declarations, package export targets resolve, and local documentation links remain valid;
3. all unit and end-to-end tests pass above the enforced 80% line, 65% branch, and 80% function coverage floors;
4. package contents contain no databases, environment files, credentials, or platform state;
5. fresh package consumers can scaffold and build;
6. representative applications pass browser interaction, console/error, accessibility-tree, and responsive-layout checks;
7. npm run conformance passes against a packed release through browser auth, CLI device authorization, live synchronization, user isolation, deployment, migration, failed activation, rollback, and data restoration;
8. npm run security:audit verifies dependency, package-content, current-tree and reachable-history credential patterns, governance, least-privilege, immutable-action, OIDC, and evidence requirements; and
9. deterministic chaos tests prove worker reclaim/fencing, corrupt-backup fail-closed behavior, and ingress recovery.

Clank deliberately does not install a TypeScript package. Its built-in compiler validates syntax lowering, while the checked-in declarations define the consumer contract. Run tsc --noEmit as an additional semantic type check when a separately provisioned, trusted TypeScript compiler is available; do not describe that optional external tool as part of the zero-dependency gate.

See docs/security.md and docs/platform-security.md for the separate security checklists.