Maintain DomoDomo quality, privacy, security, correctness, linting, builds, validation, and safe local tool behavior. Use when reviewing changes, hardening code, adding tests, auditing a feature, or preparing a contribution for merge.
Maintain DomoDomo quality, privacy, security, correctness, linting, builds, validation, and safe local tool behavior. Use when reviewing changes, hardening code, adding tests, auditing a feature, or preparing a contribution for merge.
DomoDomo Quality and Security
Maintain Cross-cutting reliability and security practices for a local-first application that processes user files and sensitive content.
Operating contract
Scope: Cross-cutting reliability and security practices for a local-first application that processes user files and sensitive content.
Primary files: package.json, scripts/, src/, backend/, mcp-server/, .gitignore, and every changed feature surface.
Before changing code: Read the full diff, relevant threat boundary, existing validation pattern, affected user data path, and available build or test command before approving a change.
01. diff inspection
For diff inspection, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For diff inspection, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For diff inspection, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For diff inspection, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For diff inspection, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For diff inspection, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For diff inspection, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For diff inspection, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For diff inspection, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For diff inspection, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For diff inspection, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For diff inspection, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For diff inspection, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For diff inspection, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For diff inspection, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For diff inspection, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
For diff inspection, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
For diff inspection, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For diff inspection, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For diff inspection, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For diff inspection, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
02. TypeScript correctness
For TypeScript correctness, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For TypeScript correctness, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For TypeScript correctness, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For TypeScript correctness, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For TypeScript correctness, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For TypeScript correctness, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For TypeScript correctness, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For TypeScript correctness, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For TypeScript correctness, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For TypeScript correctness, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For TypeScript correctness, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For TypeScript correctness, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For TypeScript correctness, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For TypeScript correctness, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For TypeScript correctness, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For TypeScript correctness, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
03. ESLint compliance
For ESLint compliance, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For ESLint compliance, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For ESLint compliance, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For ESLint compliance, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For ESLint compliance, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For ESLint compliance, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For ESLint compliance, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For ESLint compliance, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For ESLint compliance, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For ESLint compliance, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For ESLint compliance, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For ESLint compliance, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For ESLint compliance, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For ESLint compliance, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For ESLint compliance, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For ESLint compliance, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
For ESLint compliance, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
04. Vite production builds
For Vite production builds, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For Vite production builds, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For Vite production builds, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For Vite production builds, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For Vite production builds, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For Vite production builds, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For Vite production builds, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For Vite production builds, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For Vite production builds, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For Vite production builds, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For Vite production builds, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For Vite production builds, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For Vite production builds, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For Vite production builds, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For Vite production builds, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For Vite production builds, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
05. MCP TypeScript builds
For MCP TypeScript builds, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For MCP TypeScript builds, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For MCP TypeScript builds, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For MCP TypeScript builds, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For MCP TypeScript builds, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For MCP TypeScript builds, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For MCP TypeScript builds, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For MCP TypeScript builds, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For MCP TypeScript builds, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For MCP TypeScript builds, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For MCP TypeScript builds, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For MCP TypeScript builds, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For MCP TypeScript builds, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For MCP TypeScript builds, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For MCP TypeScript builds, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For MCP TypeScript builds, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
06. input validation
For input validation, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For input validation, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For input validation, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For input validation, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For input validation, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For input validation, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For input validation, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For input validation, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For input validation, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For input validation, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For input validation, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For input validation, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For input validation, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For input validation, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For input validation, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For input validation, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
For input validation, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
07. file type validation
For file type validation, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For file type validation, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For file type validation, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For file type validation, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For file type validation, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For file type validation, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For file type validation, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For file type validation, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For file type validation, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For file type validation, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For file type validation, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For file type validation, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For file type validation, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For file type validation, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For file type validation, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For file type validation, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
08. file size validation
For file size validation, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For file size validation, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For file size validation, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For file size validation, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For file size validation, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For file size validation, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For file size validation, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For file size validation, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For file size validation, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For file size validation, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For file size validation, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For file size validation, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For file size validation, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For file size validation, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For file size validation, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For file size validation, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
09. path traversal prevention
For path traversal prevention, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For path traversal prevention, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For path traversal prevention, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For path traversal prevention, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For path traversal prevention, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For path traversal prevention, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For path traversal prevention, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For path traversal prevention, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For path traversal prevention, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For path traversal prevention, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For path traversal prevention, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For path traversal prevention, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For path traversal prevention, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For path traversal prevention, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For path traversal prevention, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For path traversal prevention, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
10. command injection prevention
For command injection prevention, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For command injection prevention, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For command injection prevention, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For command injection prevention, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For command injection prevention, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For command injection prevention, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For command injection prevention, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For command injection prevention, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For command injection prevention, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For command injection prevention, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For command injection prevention, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For command injection prevention, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For command injection prevention, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For command injection prevention, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For command injection prevention, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For command injection prevention, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
11. XSS prevention
For XSS prevention, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For XSS prevention, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For XSS prevention, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For XSS prevention, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For XSS prevention, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For XSS prevention, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For XSS prevention, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For XSS prevention, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For XSS prevention, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For XSS prevention, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For XSS prevention, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For XSS prevention, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For XSS prevention, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For XSS prevention, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For XSS prevention, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For XSS prevention, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
For XSS prevention, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
12. secret handling
For secret handling, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For secret handling, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For secret handling, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For secret handling, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For secret handling, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For secret handling, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For secret handling, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For secret handling, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For secret handling, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For secret handling, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For secret handling, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For secret handling, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For secret handling, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For secret handling, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For secret handling, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For secret handling, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
For secret handling, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
13. privacy-preserving logs
For privacy-preserving logs, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For privacy-preserving logs, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For privacy-preserving logs, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For privacy-preserving logs, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For privacy-preserving logs, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For privacy-preserving logs, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For privacy-preserving logs, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For privacy-preserving logs, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For privacy-preserving logs, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For privacy-preserving logs, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For privacy-preserving logs, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For privacy-preserving logs, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For privacy-preserving logs, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For privacy-preserving logs, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For privacy-preserving logs, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For privacy-preserving logs, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
14. dependency review
For dependency review, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For dependency review, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For dependency review, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For dependency review, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For dependency review, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For dependency review, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For dependency review, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For dependency review, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For dependency review, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For dependency review, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For dependency review, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For dependency review, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For dependency review, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For dependency review, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For dependency review, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For dependency review, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
For dependency review, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
15. resource cleanup
For resource cleanup, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For resource cleanup, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For resource cleanup, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For resource cleanup, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For resource cleanup, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For resource cleanup, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For resource cleanup, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For resource cleanup, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For resource cleanup, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For resource cleanup, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For resource cleanup, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For resource cleanup, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For resource cleanup, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For resource cleanup, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For resource cleanup, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For resource cleanup, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
For resource cleanup, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
16. error boundary behavior
For error boundary behavior, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For error boundary behavior, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For error boundary behavior, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For error boundary behavior, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For error boundary behavior, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For error boundary behavior, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For error boundary behavior, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For error boundary behavior, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For error boundary behavior, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For error boundary behavior, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For error boundary behavior, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For error boundary behavior, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For error boundary behavior, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For error boundary behavior, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For error boundary behavior, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For error boundary behavior, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
17. accessibility verification
For accessibility verification, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For accessibility verification, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For accessibility verification, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For accessibility verification, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For accessibility verification, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For accessibility verification, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For accessibility verification, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For accessibility verification, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For accessibility verification, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For accessibility verification, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For accessibility verification, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For accessibility verification, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For accessibility verification, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For accessibility verification, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For accessibility verification, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For accessibility verification, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
18. manual regression testing
For manual regression testing, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For manual regression testing, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For manual regression testing, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For manual regression testing, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For manual regression testing, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For manual regression testing, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For manual regression testing, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For manual regression testing, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For manual regression testing, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For manual regression testing, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For manual regression testing, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For manual regression testing, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For manual regression testing, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For manual regression testing, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For manual regression testing, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For manual regression testing, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
19. security review evidence
For security review evidence, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For security review evidence, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For security review evidence, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For security review evidence, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For security review evidence, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For security review evidence, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For security review evidence, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For security review evidence, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For security review evidence, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For security review evidence, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For security review evidence, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For security review evidence, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For security review evidence, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For security review evidence, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For security review evidence, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For security review evidence, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
20. merge readiness
For merge readiness, establish the exact user-facing outcome and explicitly state which behavior is intentionally out of scope.
For merge readiness, read the nearest existing implementation before creating files, types, helpers, or a second pattern for the same job.
For merge readiness, map every caller, consumer, and persisted or exported output affected by this area before changing a contract.
For merge readiness, prefer the smallest local implementation that fits the established DomoDomo architecture and preserves offline behavior.
For merge readiness, use explicit TypeScript or Python types at boundaries; reject malformed values early and explain recovery to the user.
For merge readiness, keep user files, prompts, tokens, metadata, and derived artifacts on the device unless a documented local service is required.
For merge readiness, avoid adding a remote dependency, analytics call, credential requirement, or hidden network transfer to solve a local workflow.
For merge readiness, design empty, invalid, loading, cancellation, permission-denied, and failure states before treating the happy path as complete.
For merge readiness, release resources deterministically: revoke object URLs and terminate workers, listeners, streams, timers, and subscriptions.
For merge readiness, bound memory, CPU, and rendering work for large inputs; provide progress and a clear limit instead of freezing the interface.
For merge readiness, reuse DomoDomo visual patterns, semantic controls, labels, focus behavior, responsive rules, and accessible feedback.
For merge readiness, keep identifiers stable and align names, categories, descriptions, paths, exports, and documentation across all affected surfaces.
For merge readiness, record non-obvious browser, model, file-format, hardware, or platform limitations where agents and users will encounter them.
For merge readiness, treat logs, exception messages, generated artifacts, and command output as potentially sensitive; minimize what is retained or shown.
For merge readiness, verify that retries and repeated actions are safe and do not duplicate records, leak handles, or leave stale UI state.
For merge readiness, test the narrowest realistic scenario first, then test a large or slow input and a user interruption before declaring success.
For merge readiness, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
Completion standard
Confirm every changed surface follows this playbook and its local-first constraints.
Confirm applicable documentation, About metrics, technical records, and blog content accurately describe the final behavior.
Confirm the handoff records the commands run, validation outcome, known limits, and intentionally deferred work.
For TypeScript correctness, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
For TypeScript correctness, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For TypeScript correctness, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For TypeScript correctness, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For TypeScript correctness, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
For ESLint compliance, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For ESLint compliance, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For ESLint compliance, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For ESLint compliance, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
For Vite production builds, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
For Vite production builds, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For Vite production builds, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For Vite production builds, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For Vite production builds, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
For MCP TypeScript builds, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
For MCP TypeScript builds, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For MCP TypeScript builds, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For MCP TypeScript builds, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For MCP TypeScript builds, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
For input validation, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For input validation, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For input validation, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For input validation, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
For file type validation, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
For file type validation, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For file type validation, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For file type validation, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For file type validation, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
For file size validation, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
For file size validation, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For file size validation, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For file size validation, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For file size validation, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
For path traversal prevention, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
For path traversal prevention, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For path traversal prevention, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For path traversal prevention, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For path traversal prevention, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
For command injection prevention, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
For command injection prevention, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For command injection prevention, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For command injection prevention, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For command injection prevention, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
For XSS prevention, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For XSS prevention, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For XSS prevention, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For XSS prevention, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
For secret handling, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For secret handling, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For secret handling, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For secret handling, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
For privacy-preserving logs, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
For privacy-preserving logs, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For privacy-preserving logs, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For privacy-preserving logs, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For privacy-preserving logs, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
For dependency review, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For dependency review, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For dependency review, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For dependency review, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
For resource cleanup, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For resource cleanup, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For resource cleanup, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For resource cleanup, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
For error boundary behavior, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
For error boundary behavior, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For error boundary behavior, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For error boundary behavior, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For error boundary behavior, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
For accessibility verification, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
For accessibility verification, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For accessibility verification, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For accessibility verification, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For accessibility verification, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
For manual regression testing, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
For manual regression testing, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For manual regression testing, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For manual regression testing, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For manual regression testing, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
For security review evidence, inspect the final diff for accidental generated files, credentials, databases, model data, unrelated refactors, and false claims.
For security review evidence, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For security review evidence, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For security review evidence, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For security review evidence, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
For merge readiness, run the applicable project command and report its result; do not infer correctness from a visual inspection alone.
For merge readiness, update product-facing documentation, technical records, metrics, and blog content whenever this area changes a public capability.
For merge readiness, preserve unrelated working-tree changes and do not rewrite another contributor’s implementation without explicit scope.
For merge readiness, finish with a concise handoff that identifies changed files, verification evidence, limitations, and remaining follow-up work.
