Required controls

• Responsive browser interface
• Accessibility
• Navigation and routing
• Browser compatibility
• Performance
• Security controls
• Deployment and delivery
• Acceptance evidence
• Local release is a deployment boundary, not permission to replace approved business features with demonstrations. Implement and persist selected core workflows locally without requiring public hosting or external credentials. Only external delivery/provider activation may remain pending. Distinguish working locally, awaiting external configuration, not selected and incomplete. Demo seeds must be explicitly labelled, isolated from real records and replaceable; disabled controls, hard-coded records and success-only UI are not delivered capabilities.
• Reconcile the current protected baseline, approved brief, user roles and implementation before building. A stale local profile or project note must not silently downgrade an approved capability. Resolve conflicts through explicit baseline approval. Do not add payments, guest accounts, multiple properties or staff roles unless approved. Local/private/public modes must preserve the same selected business requirements, with separate readiness for each mode.
• Generate a capability-to-evidence checklist and executable release check for every selected capability and applicable pattern requirement. Bind evidence to the exact project, current baseline and source revision or content digest, environment, test command, result and evidence artifact. Missing, failed, stale or demonstration-only evidence blocks a complete verdict; an explicitly approved deferral must identify its scope and effect and never count as passed. Distinguish runnable preview, complete local application and public-release readiness. Build success, rendered screens, contract pins, source-string assertions and absence of starter markers alone cannot establish completion. Rerun affected evidence after changes and report unresolved obligations individually.
• Derive dashboard metrics, readiness, record counts and last-updated/synchronisation timestamps from real persisted state and documented calculations. Show truthful empty, loading, stale, failure and sample states. Never fabricate a freshness time, readiness percentage or completed business action. A saved indicator requires confirmed persistence; incomplete integrations cannot be described as ready.
• Verify actual keyboard and assistive-technology journeys, not only semantic markup: dialogs move and contain focus, support Escape and restore focus; calendars expose dates, state and selection without colour alone; navigation and forms have usable labels, errors and announcements. Test public and admin layouts at narrow and wide widths, touch targets, zoom, overflow and reduced motion. Include loading, empty, validation, server failure, retry, disabled-action explanations and unsaved-change handling.
• Persist valid submissions before notification delivery, return a stable reference and prevent duplicate submissions. Supply a working owner inbox/detail/action workflow for the approved form purpose. Implement a durable notification queue with templates, retries, delivery status and auditable failures; delivery failure must not lose the record. Provide local test-delivery capture with no real external sends. Include a visible provider configuration flow, private credential handoff, sender setup and test-delivery action before external enablement.
• Before collecting real personal data, agree and implement purpose, minimisation, retention, authorised access, export/deletion and applicable public privacy/terms information. Keep test data separate, do not invent legal assurances, and do not require unrelated marketing consent to submit a service request. Enable optional tracking only under the approved consent policy.
• Drive public metadata from published content and verify canonical URLs, sitemap entries, accurate structured data when appropriate and private-route indexing exclusions. Apply the approved AI-training preference independently from search visibility using supported crawler directives; explain that crawler preferences are not access control or a guarantee of compliance. Do not publish fictional facts as verified structured data. Verify production origin and updated metadata after content changes.
• For approved local auth, content API, notification or payment integrations, implement secure configuration from CogentSpec Access & integrations; the user must not edit environment/configuration files or paste secrets into chat. Deliver .coge/integration-bindings.json with {protocol:2,projectId,runtimeId,integrations:[{id,kind,capabilityId,fields:[{name,required}]}]}. Binding IDs are stable and unique, default auth-signin, external-api or supporting-service when there is only one of that kind; expose exact IDs and required fields in the application's setup guidance. Bind only approved providers, destinations and capabilities: auth to user_accounts/backend_administration, api to content_api_integration, service to forms_notifications/payments_checkout/content_api_integration. Use the exact current project/runtime identities. This manifest must contain no secrets. Implement .coge/integration-provisioner.mjs reading one protocol-2 stdin object {protocol,operation:'configure_integration',jobId,projectId,runtimeId,entryId,kind,integrationId,environment:'local',configuration:[{name,value}]}. Independently check identity, declared field schema, approved provider and callback/destination allowlists, and trusted local owner authority; reject remote/shared/production targets. Never send credentials to a user-entered arbitrary URL, enable new scope, grant new roles, create provider accounts or perform chargeable/destructive test calls. Persist secrets using an OS credential vault or authenticated encryption with an OS-protected key outside the repository and application public directories; no plaintext config files, source, Git, argv, environment, logs, telemetry or chat. Wire the actual app/provider configuration to that store so settings work across application restarts; merely writing a vault entry is not application. Apply atomically with rollback of last working configuration on failure. Job replay must be idempotent, entry/environment scoped, and support explicit rotation without resetting user accounts. Reject out-of-order jobs and mismatched bindings. Preserve protected access and do not bypass authentication for configuration. Verify the application's effective configuration and provider connection using the least-privilege non-destructive probe; OAuth interactive consent or missing provider registration is pending, not verified. Output only {jobId,projectId,integrationId,environment:'local',status:'verified',configurationApplied:true,connectionVerified:true,persisted:true} after actual verification. If durable configuration works but provider verification requires action, output status:'applied',configurationApplied:true,persisted:true without claiming verification. Fail nonzero otherwise, with no secret diagnostics on stdout/stderr. Include tests for wrong project/runtime/provider/field, contract restrictions, missing credentials, rotation, duplicate delivery, failed connection, interactive OAuth pending, rollback, encrypted persistence/restart, access protection and secret redaction. Removing a CogentSpec record is not revocation or deletion of provider/application configuration. Staging/production need a separately authorised deployment flow. When an approved integration requires asymmetric credentials, support optional key-based authentication rather than requiring every project to create keys. Protocol 3 adds keyPair:{algorithm,privateKey,publicKey,fingerprint,createdAt} to the private stdin payload; never request keys through AI/chat. The protocol-2 binding manifest must explicitly declare keyPair:{required,algorithms:['p256' or 'rsa-3072' or 'ed25519'],privateFormat:'pkcs8-pem',publicFormat:'spki-pem'} for supported key integrations. Select only provider-compatible algorithms and formats, validate public/private correspondence and fingerprint, and return keyFingerprint matching the applied key in every successful receipt. Store private keys using the protected app store, never public assets, source, logs or telemetry. Support provider-issued PEM import or generation when appropriate; unsupported OpenSSH, encrypted PEM, certificate chains or JSON key bundles must report provider-specific setup required, not silently convert or claim success. Provide public-key registration guidance; never automatically register or revoke a provider key without an authorised provider flow. Distinguish key stored, provider registration pending, configuration applied and connection verified. Key replacement must be explicit; maintain the last working application key until atomic application succeeds, retain rollback securely and provide provider-specific revocation guidance. Never regenerate on save, restart or rebuild. Bind keys to exact entry, environment, integration and project; local credentials must not silently carry into production. Hosting key records are storage-only until a separately authorised deployment adapter exists. Test incompatible keys, mismatched fingerprints, private-key redaction, repeat saves, stale replacement, rollback, restart persistence, wrong-project/runtime and pending provider registration.

Starting capabilities

• Forms and notificationsCapture submissions and deliver appropriate notifications.
• AI & Search discoverabilityBuild public content as crawlable HTML with semantic structure, stable URLs, sitemaps, canonical links, accurate structured data, attribution, and dates. Allow search crawlers, exclude private routes, and keep AI training permission separate.
• Analytics and consentMeasure use while respecting consent and privacy choices.
• Automated functional testingVerify key journeys and regressions automatically.

Starting defaults

Layout

Classical and balanced (recommended)

Build approach

No preference

Content

Project files

Foundation

Let CogentSpec choose (recommended)