HARD PROHIBITION — REPLIT AGENT

Do not use, invoke, open, delegate to, or interact with Replit Agent or Replit AI.

Replit Agent and Replit AI are permanently prohibited because they can incur paid usage.

ENTERPRISE SOFTWARE ENGINEERING STANDARD

Purpose

This standard applies to every new software project.

Every project must be designed as a real, long-lived commercial system rather than a disposable personal side project.

The objective is not to add unnecessary enterprise ceremony. The objective is to establish strong foundations early so that the system can safely support:

• real users;
• confidential data;
• financial transactions;
• business-critical workflows;
• multiple employees and administrators;
• third-party integrations;
• increased traffic;
• audits;
• incidents;
• handover to other engineers;
• long-term operation.

A project is not considered production-ready merely because it builds, passes basic tests, or appears to work in a browser.

Production readiness requires evidence across security, correctness, privacy, recovery, operations, performance, and maintainability.

CONTROL LABELS

Every requirement uses one of these labels:

[M] Mandatory

Required for every project before the relevant lifecycle gate.

An [M] requirement cannot be skipped informally.

[C] Conditionally mandatory

Required when the stated risk or feature exists.

Examples include payments, file uploads, health information, multi-tenancy, messaging, destructive workers, or regulated data.

[O] Optional or advanced

Not required for every project, but strongly recommended when scale, risk, customer expectations, or economics justify it.

Exception rule

Any exception to an [M] or applicable [C] requirement requires a written decision record containing:

• requirement being waived;
• business reason;
• technical reason;
• risk created;
• compensating control;
• responsible owner;
• expiry date;
• review date;
• plan to remove the exception.

Permanent undocumented exceptions are prohibited.

PROJECT LIFECYCLE GATES

Every project must pass explicit gates.

Gate 0 — Project authorization

Before significant development.

Gate 1 — Architecture foundation

Before major feature development.

Gate 2 — Internal environment

Before internal users or realistic data.

Gate 3 — External beta

Before inviting external users.

Gate 4 — Production launch

Before relying on the project commercially.

Gate 5 — Scale and enterprise operation

Before major customer, revenue, regulatory, or traffic expansion.

No gate may be treated as passed without a written checklist and evidence.

1. PROJECT CHARTER AND OWNERSHIP

[M] Project charter

Every project must begin with a short written charter defining:

• project name;
• business owner;
• technical owner;
• primary users;
• problem being solved;
• critical workflows;
• data collected;
• external providers;
• expected launch environment;
• expected scale;
• countries or markets;
• commercial model;
• what failure would mean;
• whether current data is disposable;
• whether downtime is acceptable.

[M] Criticality classification

Classify the project:

Level 1 — Internal or pre-user

No external users and no valuable production data.

Level 2 — Public noncritical

External users, but limited sensitive data and limited business dependency.

Level 3 — Business critical

Real customers, important operations, meaningful revenue, confidential information, or contractual commitments.

Level 4 — High assurance

Regulated information, material financial processing, healthcare, identity verification, safety-sensitive functions, enterprise contractual requirements, or severe incident impact.

The classification controls the depth of testing, recovery, monitoring, and audit.

[M] Responsibility matrix

Assign an owner for:

• application;
• database;
• infrastructure;
• security;
• privacy;
• backups;
• incident response;
• external providers;
• billing;
• user support;
• production deployment.

One person may hold multiple roles, but no responsibility may be undefined.

2. REPOSITORY AND SOURCE CONTROL

[M] Repository from the first meaningful change

All source, migrations, configuration templates, operational scripts, and documentation must be version controlled.

[M] Protected production branch

The production branch must be identified explicitly.

Once the project becomes externally accessible:

• direct force-push must be prohibited;
• changes must use reviewable commits;
• branch protection should require checks;
• emergency exceptions must be documented.

[M] Clean commits

Commits must:

• represent one coherent change;
• use descriptive messages;
• exclude secrets;
• exclude build output unless intentionally versioned;
• exclude local databases;
• exclude logs;
• exclude temporary files;
• exclude private customer data.

[M] Change traceability

Every production change must be traceable to:

• a requirement;
• a bug;
• a security finding;
• an operational task;
• or a documented decision.

[O] Signed commits and release tags

Use signed commits and signed release tags for high-assurance projects or larger teams.

3. DEVELOPMENT ENVIRONMENT

[M] Reproducible setup

The repository must document:

• supported runtime versions;
• package manager;
• installation command;
• environment variables;
• database setup;
• test commands;
• build command;
• local start command.

[M] Version pinning

Pin:

• runtime major version;
• package manager;
• lockfile;
• important build tools;
• database major version where practical.

[M] Environment separation

Development, test, staging, and production must not accidentally share:

• databases;
• storage;
• provider credentials;
• message recipients;
• analytics;
• queues;
• webhooks.

[M] Safe test mode

Tests must fail closed when provider fakes or test guards are missing.

A test environment must never send:

• real email;
• real SMS;
• real WhatsApp;
• real push notifications;
• real payments;
• real refunds;
• real deletion requests;
• real production webhooks.

[O] Development containers

Use containers or equivalent reproducible environments when they materially improve consistency.

4. ARCHITECTURE

[M] Architecture document

Document:

• major components;
• service boundaries;
• database;
• storage;
• queues;
• external integrations;
• trust boundaries;
• data flows;
• deployment environment.

[M] Prefer the simplest architecture that safely supports the business

A modular monolith is generally preferable to premature microservices.

A new service requires a documented reason such as:

• independent scaling;
• isolation;
• separate trust boundary;
• regulatory separation;
• materially different runtime;
• independent release requirement.

[M] Explicit module boundaries

Business domains must not become an uncontrolled collection of route handlers and shared utilities.

Important domains should have clear ownership, such as:

• identity;
• customers;
• partners;
• orders;
• billing;
• files;
• notifications;
• administration;
• reporting.

[M] Architecture decision records

Create short decision records for important choices:

• database;
• authentication;
• hosting;
• tenancy model;
• file storage;
• payment architecture;
• event or job architecture;
• analytics;
• deletion strategy;
• backup strategy.

[O] Event-driven architecture

Use events only where they improve decoupling, auditability, or resilience.

Do not introduce events merely to appear enterprise-grade.

5. THREAT MODELING

[M] Initial threat model

Before public launch, document:

• assets;
• attackers;
• entry points;
• trust boundaries;
• privileged actors;
• abuse cases;
• irreversible actions;
• likely failure modes.

[M] Abuse-case review

Consider:

• account takeover;
• credential stuffing;
• spam;
• fake registrations;
• enumeration;
• data scraping;
• privilege escalation;
• cross-tenant access;
• malicious uploads;
• webhook forgery;
• payment manipulation;
• referral abuse;
• automation abuse;
• denial of service;
• administrator misuse.

[M] Threat-model updates

Update the threat model when adding:

• payments;
• uploads;
• messaging;
• admin capabilities;
• background workers;
• public APIs;
• AI agents;
• third-party data imports;
• destructive actions;
• multi-tenancy;
• sensitive data.

6. IDENTITY AND AUTHENTICATION

[M] Use a mature identity system

Do not design custom password cryptography or session systems without a compelling documented need and specialist review.

[M] Secure session handling

Sessions must have:

• secure cookies where cookies are used;
• HTTP-only protection;
• appropriate SameSite behavior;
• expiry;
• revocation;
• server-side validation;
• rotation or refresh protection.

[M] Authentication-flow tests

Test:

• sign-up;
• sign-in;
• sign-out;
• expired session;
• invalid session;
• password reset;
• email or phone verification;
• revoked user;
• disabled user;
• duplicate identity;
• callback tampering;
• open redirect attempts.

[M] Anti-enumeration

Authentication and recovery endpoints must not unnecessarily reveal whether an account exists.

[C] Multi-factor authentication

Mandatory for:

• administrators;
• infrastructure owners;
• financial operators;
• projects handling highly sensitive or regulated data.

[O] Passkeys

Consider passkeys for high-value accounts or products where user adoption is practical.

7. AUTHORIZATION AND TENANT ISOLATION

[M] Server-side authorization

Every protected operation must enforce authorization on the server.

Hidden buttons and client-side route guards are not authorization.

[M] Deny by default

When actor, role, ownership, tenant, status, or configuration is ambiguous, deny access.

[M] Resource ownership checks

Every resource access must establish:

• who the actor is;
• what role they hold;
• which tenant or organization they belong to;
• whether they own or may access the resource;
• whether the resource status allows the action.

[M] Negative authorization tests

Tests must prove:

• user A cannot access user B;
• tenant A cannot access tenant B;
• ordinary user cannot access admin actions;
• former owner cannot access reassigned resources;
• soft-deleted resources remain inaccessible;
• expired tokens do not work.

[C] Database-level isolation

Mandatory where:

• clients access the database directly;
• multi-tenancy risk is high;
• sensitive data requires defense in depth.

Use RLS, separate schemas, or another proven model where appropriate.

[M] Administrative authorization

Admin status must not be determined by a user-editable profile field.

8. ADMINISTRATION AND SUPPORT ACCESS

[M] Separate admin surface

Administrative capabilities must be explicitly separated from ordinary user capabilities.

[M] Least privilege

Administrators should receive only the access required for their duties.

[M] Audit logging

Record high-risk administrative activity:

• actor;
• action;
• target;
• time;
• result;
• safe reason or metadata.

[M] Destructive confirmation

High-impact actions require explicit confirmation and, where appropriate:

• reauthentication;
• typed confirmation;
• dual approval;
• delay;
• reversible status before permanent deletion.

[C] Impersonation controls

When support impersonation exists:

• require elevated permission;
• display persistent indication;
• log start and end;
• prevent sensitive actions where possible;
• never reveal authentication secrets.

9. DATA CLASSIFICATION AND PRIVACY

[M] Data inventory

Maintain an inventory of data collected, generated, stored, transferred, and deleted.

[M] Data classes

Classify data:

Public

Safe for intentional public release.

Internal

Operational information not intended for the public.

Confidential

Customer, partner, business, or employee information requiring controlled access.

Restricted

Authentication secrets, payment credentials, government identifiers, health data, highly sensitive personal data, or other severe-impact information.

[M] Data minimization

Do not collect data merely because it may be useful later.

[M] Purpose limitation

Document why each category of personal or confidential data is required.

[M] Retention schedule

Define:

• retention period;
• deletion trigger;
• legal or business justification;
• backup-retention behavior;
• exceptions.

[M] Data deletion

Deletion must be:

• authorized;
• scoped;
• auditable;
• resilient to retries;
• explicit about what is not deleted;
• tested.

[C] Privacy impact assessment

Mandatory before processing:

• large-scale personal data;
• children’s data;
• government identifiers;
• health data;
• precise location;
• biometrics;
• systematic monitoring;
• other high-risk categories.

Legal interpretation must be reviewed by qualified counsel.

10. SECRETS AND KEY MANAGEMENT

[M] No secrets in source control

Never commit:

• API keys;
• passwords;
• database URLs;
• private keys;
• webhook secrets;
• encryption keys;
• access tokens.

[M] Managed secret storage

Production secrets must be held by the deployment or secret-management system.

[M] Secret separation

Use separate credentials for:

• development;
• testing;
• staging;
• production.

[M] Secret rotation plan

Document how each important secret is rotated without unacceptable downtime.

[M] Fail closed

Missing sensitive configuration must disable the feature or prevent startup.

It must not enable an insecure fallback.

[M] Redaction

Secrets and full connection strings must never appear in:

• logs;
• error responses;
• analytics;
• reports;
• screenshots;
• test snapshots.

[C] Central key-management service

Mandatory for high-assurance systems with application-managed encryption keys.

11. DATABASE ENGINEERING

[M] Versioned migrations

All schema changes must use reviewed, versioned migrations.

Manual production schema edits are prohibited except documented emergency recovery.

[M] Database constraints

Critical invariants must be enforced with appropriate:

• primary keys;
• foreign keys;
• unique constraints;
• check constraints;
• nullability;
• indexes.

Do not rely solely on application code for invariants whose violation would corrupt business state.

[M] Transaction design

Transactions must:

• be short;
• cover one logical atomic change;
• avoid unnecessary external I/O;
• have clear failure behavior.

[M] External side-effect separation

Do not hold ordinary database transactions open while waiting on:

• payment providers;
• email;
• messaging;
• object storage;
• external APIs.

Use claims, outboxes, compensation, or another reviewed pattern.

[M] Query safety

Use parameterized queries.

Dynamic identifiers, sorting, and filters must use allowlists.

[M] Index review

Indexes must support:

• authorization predicates;
• high-volume filters;
• foreign keys;
• worker claims;
• pagination;
• uniqueness requirements.

[M] Database connection control

The live application must not use an unnecessarily powerful owner or migration account.

Use separate credentials for:

• application runtime;
• migrations;
• security-sensitive ownership where required.

[C] Row-level security

Mandatory where clients access the database or where it materially improves tenant isolation.

[O] Read replicas and partitioning

Introduce only after measured need.

12. MIGRATION SAFETY

[M] Migration review

Every migration must be reviewed for:

• data loss;
• lock duration;
• table rewrites;
• backward compatibility;
• failure recovery;
• deployment ordering;
• rollback limitations.

[M] Expand-and-contract deployment

For high-risk changes, prefer:

1. Add compatible schema.
2. Deploy compatible code.
3. Backfill.
4. Switch reads and writes.
5. Verify.
6. Remove old schema later.

[M] Production preflight

Before a major migration confirm:

• expected current version;
• pending migration list;
• database engine version;
• privileges;
• extensions;
• row volumes;
• lock and timeout risks;
• maintenance requirements.

[M] Startup schema check

The application should refuse unsafe startup when the database schema is incompatible.

[C] Maintenance window

Mandatory when old and new application versions cannot safely operate against the same schema.

[M] Irreversible migration declaration

A migration that destroys or irreversibly transforms data must state this explicitly.

13. FILES AND OBJECT STORAGE

[C] Upload threat model

Mandatory whenever users or administrators can upload files.

[C] Upload controls

Implement:

• authentication;
• authorization;
• ownership;
• size limits;
• count limits;
• filename normalization;
• random object keys;
• MIME validation;
• content inspection where practical;
• extension policy;
• safe download headers;
• private-by-default storage for confidential files.

[C] Dangerous file types

HTML, SVG, scripts, executable files, macros, and archives require explicit handling or prohibition.

[C] Malware scanning

Mandatory when:

• external users exchange files;
• enterprise customers expect it;
• files are redistributed;
• accepted formats are high risk.

[C] Signed access

Private files should use short-lived authorized access rather than permanent public URLs.

[M] Deletion and recovery decision

Document whether deleted objects are:

• recoverable;
• versioned;
• retained;
• or permanently irreversible.

Do not enable automatic irreversible deletion without explicit approval.

14. API ENGINEERING

[M] Explicit schemas

Every external input must be validated using an explicit schema.

[M] Unknown-field policy

Reject unknown fields for sensitive write operations unless there is a documented compatibility reason.

[M] Input bounds

Define limits for:

• strings;
• arrays;
• numbers;
• dates;
• files;
• pagination;
• query complexity.

[M] Safe error responses

Public errors must not expose:

• stack traces;
• SQL;
• file paths;
• secrets;
• provider bodies;
• internal identifiers unnecessarily.

[M] Idempotency

Create idempotency protection for retryable high-impact operations such as:

• payments;
• orders;
• account deletion;
• webhook processing;
• notification sends;
• provider cancellations;
• deal creation.

[M] Rate limiting

Protect:

• authentication;
• public forms;
• search;
• uploads;
• verification;
• password recovery;
• resource-intensive endpoints;
• webhooks where appropriate.

[M] SSRF protection

Any server-side URL fetching must control:

• schemes;
• destinations;
• redirects;
• private networks;
• metadata endpoints;
• DNS behavior;
• payload sizes;
• timeouts.

15. WEBHOOKS AND THIRD-PARTY INTEGRATIONS

[C] Signature verification

Mandatory for providers that support signed webhooks.

[C] Replay protection

Use timestamps, nonces, event IDs, or idempotency records.

[C] Duplicate and out-of-order handling

Webhook processing must remain correct when events are:

• repeated;
• delayed;
• delivered out of order;
• partially malformed.

[M] Provider abstraction

Provider-specific behavior should be isolated behind clear interfaces where practical.

[M] Provider timeouts

Every external request requires:

• connect timeout;
• total timeout;
• bounded retries;
• safe error classification.

[M] Provider logs

Do not log complete provider payloads when they contain personal or restricted information.

[C] Vendor failure plan

Document how the product behaves when a critical vendor is unavailable.

16. PAYMENTS AND FINANCIAL WORKFLOWS

[C] Financial source of truth

Define which system is authoritative for:

• payment;
• refund;
• subscription;
• commission;
• invoice;
• deal.

[C] Idempotent financial operations

Every provider-facing financial operation must be idempotent.

[C] Reconciliation

Implement reconciliation between internal records and provider records.

[C] Ambiguous-result handling

When provider status is unknown:

• do not assume success;
• do not blindly retry;
• query or reconcile;
• escalate unresolved cases.

[C] Monetary representation

Store money using integer minor units or a reviewed exact-decimal representation.

Never use uncontrolled floating-point arithmetic for financial values.

[C] Financial audit trail

Material changes require an immutable or strongly controlled history.

[C] Separation of duties

For high-value systems, consider dual approval for manual financial adjustments.

17. BACKGROUND JOBS AND WORKERS

[C] Durable jobs

Important work must not depend only on an in-memory timer.

[C] Claim and lease

Concurrent workers require:

• atomic claim;
• lease;
• stale-worker recovery;
• bounded batch;
• ownership token.

[C] Idempotent execution

Repeated processing must not duplicate harmful effects.

[C] Retry policy

Define:

• retryable errors;
• non-retryable errors;
• backoff;
• maximum attempts;
• manual review.

[C] Poison-job handling

A failing job must not permanently block the queue.

[C] Independent activation

Different destructive or provider-facing workers must be independently controllable.

Avoid a single endpoint that runs every maintenance task.

[C] Kill switch

High-risk workers require a reliable way to stop new execution.

[C] Concurrency tests

Test simultaneous claims and crash recovery using real database behavior.

18. MESSAGING AND NOTIFICATIONS

[C] Correct recipient

Prove that messages cannot be sent to the wrong customer, partner, or organization.

[C] Consent and purpose

Separate:

• transactional communication;
• operational communication;
• marketing communication.

[C] Unsubscribe handling

Marketing unsubscribe must work without disabling essential transactional messages incorrectly.

[C] Duplicate prevention

Retries must not send duplicate messages without a documented reason.

[C] Template safety

Escape or sanitize user-controlled content.

[C] Test tripwires

Provider sends must be impossible in the automated test environment.

19. ANALYTICS

[M] Analytics are not authoritative business logic

Browser analytics must not determine:

• authorization;
• qualification;
• payment;
• workflow state;
• routing;
• notifications;
• attribution used for contractual or financial decisions.

[M] Consent

Where consent is required, analytics must remain disabled until valid consent.

[M] PII exclusion

Do not send:

• names;
• emails;
• phone numbers;
• unrestricted text;
• tokens;
• raw private URLs;
• object paths;
• private identifiers.

[M] Server-authoritative business events

Important commercial state should be recorded in the application database.

20. LOGGING AND OBSERVABILITY

[M] Structured logs

Use consistent structured logging with:

• timestamp;
• severity;
• fixed event name;
• request or correlation ID;
• safe bounded metadata.

[M] Log redaction

Exclude:

• secrets;
• passwords;
• tokens;
• full provider payloads;
• unnecessary PII;
• file contents;
• raw SQL parameters containing private data.

[M] Health visibility

Operators must be able to determine:

• whether the app is running;
• whether the database is reachable;
• whether core workflows are succeeding;
• whether jobs are stuck;
• whether providers are failing.

[M] Alerts

Production alerts must cover:

• repeated crashes;
• high error rate;
• authentication anomalies;
• queue backlog;
• backup failure;
• webhook failure;
• provider failure;
• database capacity;
• disk or storage issues.

[M] Correlation

A business operation should be traceable across request, database, job, and provider boundaries without exposing sensitive content.

[O] Distributed tracing

Recommended for complex multi-service systems.

21. ERROR HANDLING AND RESILIENCE

[M] Fail safely

Failure must not leave important business state incorrectly marked complete.

[M] Timeouts

Every network and database operation requires an appropriate timeout.

[M] Bounded retries

Retries must have:

• maximum attempts;
• delay;
• jitter where appropriate;
• idempotency.

[M] Graceful shutdown

The application must stop accepting new work and finish or safely release in-progress work.

[C] Circuit breakers

Recommended or mandatory for unstable or business-critical dependencies.

[M] Degraded operation

Document what remains available when a provider is unavailable.

22. BACKUP AND DISASTER RECOVERY

[M] Recovery requirements

Before production, define:

• Recovery Point Objective;
• Recovery Time Objective;
• acceptable data loss;
• acceptable downtime.

[M] Backup inventory

Document whether backups cover:

• database;
• object storage;
• authentication;
• secrets;
• configuration;
• provider configuration;
• source code;
• deployment metadata.

[M] Valuable production data must be backed up

Once users or important business records exist, backups are mandatory.

[M] Restore testing

A backup is not considered reliable until a restore has been tested.

[M] Backup monitoring

Backup and verification failures must alert an owner.

[M] Off-site or independent copy

Business-critical backups should not exist only in the same failure domain as production.

[C] Point-in-time recovery

Mandatory when the business cannot tolerate the ordinary backup interval.

[M] Storage recovery decision

Database backup does not automatically mean object-file recovery.

Treat them as separate systems.

[O] Disaster exercise

Run a scheduled recovery exercise for Level 3 and Level 4 systems.

23. PERFORMANCE AND CAPACITY

[M] Performance budgets

Define limits for:

• page load;
• API latency;
• job duration;
• database query duration;
• payload size;
• file size;
• client bundle size.

[M] Pagination

Unbounded list endpoints are prohibited.

[M] Capacity awareness

Monitor:

• database connections;
• CPU;
• memory;
• disk;
• storage;
• queue depth;
• provider quotas;
• email/SMS limits;
• rate limits.

[C] Load testing

Mandatory before:

• a major public launch;
• high-traffic campaign;
• enterprise onboarding;
• significant architecture change.

Load tests must not target production without explicit approval.

[O] Chaos testing

Recommended for mature Level 4 systems.

24. FRONTEND ENGINEERING

[M] Secure rendering

Avoid unsafe HTML and uncontrolled script execution.

[M] Sensitive-data handling

Do not persist sensitive data in browser storage without a reviewed reason.

[M] Error boundaries

Critical interfaces require clear failure and recovery states.

[M] Responsive critical workflows

Core workflows must remain usable on supported screen sizes.

[M] Browser compatibility

Define and test supported browsers.

[M] Accessibility

Critical workflows must support:

• keyboard use;
• labels;
• focus management;
• clear error messages;
• adequate contrast;
• screen-reader status where appropriate.

[O] Formal accessibility conformance audit

Recommended for public, government, education, healthcare, or enterprise-facing products.

25. CODE QUALITY

[M] Strict type checking

Use strict typing where supported.

Avoid unnecessary any, unchecked casts, and ignored errors in critical paths.

[M] Linting and formatting

Automate consistent standards.

[M] Clear error contracts

Do not use raw exceptions as public API contracts.

[M] Small understandable modules

Do not allow single files or functions to grow without clear boundaries.

[M] No silent failure

Errors must be handled, returned, logged safely, or deliberately ignored with explanation.

[M] Comments explain why

Comments should document business rules, risk, and reasoning rather than restating obvious code.

[M] Dead-code removal

Remove abandoned implementations after safe transition.

26. TESTING STANDARD

[M] Test pyramid

Maintain an appropriate balance of:

• unit tests;
• integration tests;
• route or API tests;
• end-to-end tests.

[M] Critical workflow tests

Every critical workflow requires:

• successful path;
• authorization failure;
• validation failure;
• duplicate/retry behavior;
• dependency failure;
• concurrency where relevant;
• state-transition validation.

[M] Real production boundaries

Tests should exercise real route registration, service logic, and database behavior where practical.

A test suite composed only of mocked functions is insufficient.

[M] Database integration tests

Use disposable databases for:

• migrations;
• constraints;
• transactions;
• concurrency;
• locking;
• worker claims;
• rollback.

[M] No-op resistance

Important tests must fail when the underlying implementation is replaced by a no-op.

[M] Deterministic isolation

Tests must not depend on:

• production;
• shared databases;
• live providers;
• test order;
• persistent local state.

[C] Contract tests

Mandatory for important external integrations.

[C] Security tests

Mandatory for:

• authentication;
• authorization;
• uploads;
• webhooks;
• payments;
• admin actions;
• destructive workers.

[C] Migration tests

Mandatory for meaningful database changes.

Test:

• clean installation;
• upgrade from current production version;
• constraints;
• rollback or recovery strategy.

[O] Mutation testing

Recommended for highly critical business logic.

27. DEPENDENCIES AND SOFTWARE SUPPLY CHAIN

[M] Lockfile

Commit and review the lockfile.

[M] Dependency audit

Run vulnerability checks regularly.

Do not apply automatic breaking fixes blindly.

[M] Minimal dependencies

Every dependency increases supply-chain and maintenance risk.

[M] Supported packages

Avoid abandoned packages in security-sensitive areas.

[M] Update process

Define how security updates are evaluated and released.

[C] Software bill of materials

Mandatory for enterprise contractual requirements or high-assurance systems.

[C] Provenance and artifact signing

Recommended or mandatory for Level 4 environments.

28. CI/CD AND RELEASE MANAGEMENT

[M] Automated checks

Before production release run:

• type checking;
• linting;
• unit tests;
• integration tests;
• build;
• migration validation;
• dependency audit;
• secret scan;
• diff validation.

[M] Immutable release identification

Every deployment must identify the exact commit or release.

[M] Environment promotion

Do not rebuild materially different code separately for each environment where avoidable.

Promote a known artifact.

[M] Deployment authorization

Production deployment requires explicit authorization.

Codex must not infer authorization from discussion.

[M] Rollback or recovery plan

Every meaningful deployment must state:

• how to roll back code;
• whether schema rollback is safe;
• how to stop workers;
• how to handle partially completed jobs;
• how to communicate downtime.

[C] Canary or staged rollout

Recommended for high-risk releases and mandatory when blast radius is large.

[O] Feature flags

Useful for controlled launch, but flags must have owners and removal dates.

29. INFRASTRUCTURE SECURITY

[M] Least privilege

Runtime services must have only the permissions they need.

[M] Network exposure review

Document publicly exposed:

• ports;
• endpoints;
• admin surfaces;
• databases;
• storage;
• dashboards.

[M] TLS

Use encrypted transport for production connections.

[M] Infrastructure configuration in code or documented form

Important settings must be reproducible and reviewable.

[M] Access review

Review production and provider access periodically.

Remove former employees, contractors, and unused credentials promptly.

[C] Network restrictions

Use allowlists, private networking, or equivalent controls where compatible and valuable.

[O] Multi-region or high availability

Introduce based on required availability and measured risk.

30. INCIDENT RESPONSE

[M] Incident plan

Document:

• who is contacted;
• who leads;
• how to contain;
• how to preserve evidence;
• how to communicate;
• how to recover;
• how to document.

[M] Kill switches

Identify how to disable:

• sign-ups;
• payments;
• emails;
• messaging;
• uploads;
• webhooks;
• destructive workers;
• risky features.

[M] Security-event logging

Important events should be reconstructable without storing excessive private data.

[M] Post-incident review

After a material incident document:

• timeline;
• root cause;
• impact;
• containment;
• recovery;
• corrective actions;
• prevention;
• owners and deadlines.

[C] Customer notification procedure

Mandatory when contracts, law, or material customer impact may require notification.

Qualified counsel must determine legal obligations.

31. DOCUMENTATION

[M] Required documentation

Maintain:

• README;
• architecture;
• environment variables;
• deployment;
• migrations;
• rollback;
• database ownership;
• provider integrations;
• backups;
• restore;
• incident response;
• administration;
• data retention;
• account deletion;
• known limitations.

[M] Documentation verification

Documentation is part of the product.

Stale or false documentation is a defect.

[M] Operational runbooks

Create step-by-step runbooks for high-risk manual operations.

[O] Developer handbook

Recommended as the team grows.

32. AUDIT PROGRAMME

[M] Per-change review

Every meaningful change must be reviewed for:

• authorization;
• validation;
• transactions;
• secrets;
• data handling;
• error handling;
• tests;
• migrations;
• external side effects.

[M] Pre-launch enterprise audit

Before external production launch, perform an independent read-only audit covering:

• architecture;
• authentication;
• authorization;
• data privacy;
• APIs;
• database;
• migrations;
• files;
• providers;
• workers;
• observability;
• backups;
• recovery;
• testing;
• dependencies;
• deployment.

[M] Major-change audit

Repeat a focused audit after:

• authentication redesign;
• payment introduction;
• tenancy redesign;
• major migration;
• file-storage redesign;
• admin expansion;
• destructive worker introduction;
• provider or hosting migration;
• material security incident.

[M] Quarterly operational review for Level 3 and Level 4

Review:

• privileged access;
• secrets;
• dependency vulnerabilities;
• backup status;
• restore evidence;
• failed jobs;
• provider failures;
• capacity;
• alert coverage;
• stale feature flags;
• unresolved security findings.

[M] Annual full audit for Level 3 and Level 4

Perform a broad engineering and security audit at least annually.

[C] Independent penetration test

Mandatory before major enterprise or regulated commitments when the risk or contract justifies it.

[C] External compliance assessment

Mandatory when claiming certification or contractual compliance.

An internal code review is not a certification.

33. AUDIT FINDING MANAGEMENT

[M] Finding register

Every audit finding requires:

• ID;
• severity;
• evidence;
• affected component;
• impact;
• remediation;
• owner;
• status;
• regression test;
• target milestone;
• accepted-risk documentation where applicable.

[M] Severity discipline

Do not label hypothetical concerns Critical or High without a practical exploit or failure path.

[M] Remediation verification

A finding is not closed merely because code changed.

Closure requires:

• implementation;
• regression test;
• review;
• operational or production evidence where applicable.

[M] Risk acceptance

Accepted risk requires:

• business owner;
• technical owner;
• reason;
• compensating control;
• expiry;
• review date.

34. RELEASE GATES

Gate 0 — Authorization

Required:

• project charter;
• owners;
• criticality;
• data classification.

Gate 1 — Architecture foundation

Required:

• architecture document;
• trust boundaries;
• database decision;
• identity decision;
• environment separation;
• initial threat model.

Gate 2 — Internal environment

Required:

• basic authentication;
• server-side authorization;
• secret isolation;
• versioned migrations;
• safe tests;
• structured logging;
• critical workflow tests.

Gate 3 — External beta

Required:

• public-route audit;
• rate limits;
• privacy review;
• upload controls where applicable;
• provider/webhook controls;
• backup decision;
• incident contacts;
• admin audit logs;
• negative authorization tests.

Gate 4 — Production

Required:

• independent enterprise audit;
• no unresolved Critical findings;
• no unresolved High findings without explicit time-limited risk acceptance;
• tested deployment;
• migration preflight;
• rollback or recovery plan;
• monitored backups for valuable data;
• restore evidence;
• monitoring and alerts;
• documented support and incident procedures.

Gate 5 — Scale

Required:

• measured capacity;
• load testing;
• RTO/RPO validation;
• access review;
• provider failure drills;
• stronger deployment controls;
• formal SLOs;
• recurring audit programme.

35. OPTIONAL ADVANCED ENTERPRISE CONTROLS

Apply based on risk and scale:

[O] Security

• external penetration testing;
• bug bounty;
• runtime application protection;
• SIEM;
• hardware security keys;
• customer-managed encryption keys;
• data-loss prevention;
• formal threat-model workshops.

[O] Reliability

• active-active deployment;
• read replicas;
• multi-region failover;
• chaos engineering;
• automated disaster exercises;
• advanced queueing;
• blue/green deployment.

[O] Engineering

• internal developer platform;
• contract testing across services;
• mutation testing;
• formal specification for critical algorithms;
• performance regression gates;
• automated architecture constraints.

[O] Compliance

• evidence automation;
• policy-as-code;
• audit-log retention controls;
• vendor risk reviews;
• data-residency controls;
• formal privacy-management programme.

Optional controls must be chosen because they solve a real risk or contractual need, not because they sound enterprise-grade.

36. CODEX OPERATING RULES

[M] No production changes without explicit authorization

Codex must never:

• deploy;
• push;
• merge;
• migrate production;
• change secrets;
• provision infrastructure;
• send provider messages;
• delete data;
• enable workers

unless the user has explicitly authorized that exact action.

[M] Separate audit from remediation

An audit must remain read-only.

Do not fix findings during the same audit unless explicitly instructed after review.

[M] Preserve repository state

Before work record:

• branch;
• HEAD;
• origin/main;
• staged state;
• working tree.

After work report the same.

[M] Local safety

Use:

• fake providers;
• disposable databases;
• loopback infrastructure;
• temporary directories outside the repository.

[M] Secrets

Never request secrets in chat.

When a secret is needed, use hidden local input and do not print or persist it.

[M] Evidence

Do not claim success from test names or code appearance alone.

Inspect actual assertions and boundaries.

[M] Honest uncertainty

When production evidence is missing, state:

PRODUCTION EVIDENCE REQUIRED

Do not guess.

[M] Narrow changes

Implement the smallest coherent safe change.

Do not redesign unrelated systems during a focused task.

[M] Review before commit

For risky changes use:

1. Design.
2. Implementation.
3. Verification.
4. Independent read-only review.
5. Local commit.
6. Production plan.
7. Explicit deployment authorization.

[M] No Replit Agent

Replit Agent and Replit AI must never be used.

37. DEFINITION OF ENTERPRISE-READY

A project is enterprise-ready only when evidence shows that:

• users are correctly authenticated;
• every sensitive action is authorized;
• tenants cannot access each other;
• confidential data is protected;
• critical state is transactionally consistent;
• retries do not duplicate harmful effects;
• provider failures do not corrupt authoritative state;
• uploads are controlled;
• destructive actions are bounded and auditable;
• production access is least-privileged;
• migrations are controlled;
• deployments are reversible or recoverable;
• valuable data is backed up;
• restores have been proven;
• failures are observable;
• incidents have an owner and procedure;
• critical workflows are tested through real boundaries;
• dependencies are monitored;
• documentation matches reality;
• unresolved risks are known and owned.

A polished interface, successful build, or large test count alone does not satisfy this definition.