# AI-Assisted Website Build Profile

**Status:** Working method 0.1  
**Purpose:** Preserve the facts, authority, constraints, evidence, and continuity an AI-assisted website project needs from discovery through handoff.

## The idea

A site brief describes the desired website. A Website Build Profile also describes the system around it: the business record, audience, existing content and tools, account ownership, dependencies, delegated decisions, human gates, release evidence, and maintenance conventions.

The profile becomes portable project memory. A later human or AI session should be able to continue the work without rediscovering the business or guessing which decisions are settled.

## Core record

1. **Authority and ownership:** Project owner, decision-makers, approvers, account owners, and who may publish.
2. **Authoritative business facts:** Name, contact routes, service area, offers, pricing rules, availability conventions, legal language, and public profiles.
3. **Purpose and audience:** What the site must accomplish, who arrives, how they arrive, what they need to decide, and the next useful action.
4. **Content readiness:** What is final, usable with cleanup, scattered, missing, duplicated, or dependent on another person.
5. **Existing environment:** Domain, DNS, hosting, email, WordPress, theme, plugins, integrations, forms, analytics, media, redirects, and preserved URLs.
6. **Assets and licenses:** Ownership, renewal status, permitted use, source files, and access dependencies.
7. **Design system:** Voice, visual principles, accessibility needs, responsive behavior, interaction rules, and approved examples.
8. **Decision inventory:** Which decisions belong to the client, which are delegated to the AI, and which depend on evidence or the discovered environment.
9. **Human gates:** Credentials, payments, legal approval, destructive actions, external messages, publication, and other consequential boundaries.
10. **Verification and release:** Backups, staging state, test routes, functional checks, viewport checks, performance, accessibility, rollback plan, and proof of deployment.
11. **Maintenance and handoff:** Editing conventions, known limitations, update path, support ownership, and the smallest useful context packet for future work.

## Operating sequence

1. Establish ownership and decision authority.
2. Unlock the intended construction surface, including required licenses and accounts.
3. Perform a read-only discovery pass.
4. Inventory content, capabilities, dependencies, and missing information.
5. Assign every meaningful variable to a human, the AI, or an evidence-dependent decision.
6. Research unresolved delegated variables and state when evidence is weak.
7. Freeze a reviewable build specification.
8. Build in reversible stages and preserve recovery material.
9. Audit the result against the specification and real user journeys.
10. Repair bounded failures, publish only with authority, and verify the public result.
11. Update the profile so the handoff reflects the system that actually exists.

## Evidence rules

- Separate observed facts, client statements, interpretations, hypotheses, and completed verification.
- Record failed routes and corrections when they changed the method.
- Do not call a feature complete because code was generated; test the behavior in its real environment.
- Preserve established public addresses and plugin-managed records unless an approved migration plan replaces them.
- Keep credentials and recovery codes out of the profile. Record ownership and storage location instead.

## Success test

The profile succeeds when the project can survive a new session, a new operator, a changed environment, or a delayed return without losing settled decisions or inventing facts. The website is the visible output; continuity and recoverability are part of the product.