Work with ADEL 

I want to build a corporate marketing website for Momentum & Balance Advisory,
a professional services firm of about forty people. It should explain what the
firm does, establish credibility with prospective clients, and let a visitor
start a conversation.

Before any code or scaffolding, help me establish the initial intent.

Ask the smallest useful set of questions whose answers would materially
change the intended users, outcome, scope, important constraints, or what
success means. Do not ask about implementation, technology, or architecture
yet. If something is genuinely unknown, leave it open rather than inventing
an answer.

Stop and wait for my answers before producing the summary.

After I answer, summarise back:

Intended users
Who this is for, and any audience explicitly excluded.

Outcome
What this needs to achieve for the firm.

Confirmed scope
What we have actually agreed is included.

Proposed exclusions
Anything you think should stay out of scope. Mark these as proposals for
my confirmation, not decisions.

Confirmed facts
Important information I provided.

Assumptions and inferences
Anything you inferred rather than learned from me.

Open questions
Information that is still genuinely undecided or unknown.

Initial success
What observable result would indicate that this project is useful.

Keep the summary concise.

Stop again so I can correct or confirm the summary. After I confirm it, save
the agreed version to docs/product/intent.md. Creating that note is the only
workspace change to make at this stage.

Do not scaffold the project, choose a stack, propose architecture, or write
implementation code yet.

Read docs/product/intent.md.

First, review it against what this project's product brief will need to state.
Identify:

- anything important that is still unclear or missing
- assumptions or inferences that have not been confirmed
- questions whose answers would materially change the users, outcome,
  scope, requirements, constraints or acceptance criteria

Ask only the smallest useful set of questions needed to resolve those
points. Do not ask about architecture, technology, implementation, or
delivery planning yet.

Stop and wait for my answers.

After I answer, draft a concise product brief using the intent note and my
answers as input rather than copying the note.

Cover:

- the problem and intended users
- required outcomes and initial success
- confirmed scope
- functional requirements
- non-functional requirements
- important constraints
- acceptance criteria
- explicit exclusions
- assumptions and open questions that legitimately remain

For this walkthrough, give the functional requirements (FR) and non-functional
requirements (NFR) short, stable identifiers such as FR-01 and NFR-01. Do not create a separate
requirements register.

Keep the brief proportionate to a five-page marketing site. If a section
would only repeat something obvious or add no useful information, leave it
out.

Do not make architecture, technology, implementation, or governance
decisions in the product brief.

Where something remains uncertain, state the uncertainty instead of
resolving it silently. Clearly distinguish confirmed information from
anything you inferred.

Present the draft for my review and stop. After I confirm it, save the agreed
brief to docs/product/product-brief.md.

Read docs/product/product-brief.md.

We are establishing the project's governing principles before moving on to
system design.

First, evaluate whether this project needs project-wide principles or boundaries in
each of these areas:

- proportional engineering and architectural complexity
- protecting the agreed visitor outcome from unapproved feature growth
- personal-data and security commitments
- accessibility, responsive-use, and performance commitments
- testing, evidence, and completion claims
- technical and operational constraints
- decision authority, exceptions, and changes to the Project principles

Do not create a principle merely to fill a category. Identify only candidates
that appear important enough to constrain the whole project rather than one
feature or implementation choice.

For each candidate, distinguish whether it is:

- already confirmed by the product brief
- a reasonable inference that still needs my confirmation
- a legal, contract or audit requirement, or specialist issue, that should be verified rather
  than assumed

Do not turn implementation preferences into governing principles. Do not invent
legal, privacy, accessibility, security, architecture, or organizational
requirements merely because they would be common practice.

Ask the smallest useful set of questions needed to resolve the important
governance decisions. If a decision belongs to the client or another
approver rather than me, identify that instead of asking me to decide it.

Stop and wait for my answers.

After I answer, propose the complete set of principles, constraints, decision
authority and change rules in language I can review. For every principle,
state the rule, why it matters here, and what decisions or work it applies to.

Stop so I can correct or confirm the proposed Project principles.

After I confirm it, save the complete Project principles record to
docs/governance/project-principles.md.

Include only what needs to remain true across the project, such as:

- purpose and scope
- core principles
- technical and operational constraints
- decision authority
- exceptions and changes
- record status

Use MUST, MUST NOT, and SHOULD only where the strength of the rule matters.

Do not duplicate requirements from the product brief. Refer to it where
appropriate.

Do not make architecture, technology, or implementation decisions.

Do not write agent instructions yet. Those will be derived
later from these principles as agent instructions.

If a proposed governing principle would change or contradict the current
product brief, flag that explicitly instead of silently reconciling it.
We will update the source of truth before proceeding.

Do not create a separate complexity tracker, policy, checklist, or principle
document unless the confirmed Project principles establish a specific need for
one. Use the approved design or a relevant decision record to explain an
important complexity choice.

Read docs/product/product-brief.md and
docs/governance/project-principles.md.

We are now establishing the approved design for this project.

First, review those sources and identify any missing, conflicting, or
unresolved information that would prevent a responsible design decision.

Do not resolve a question about required product behaviour or a project-wide
governing constraint by assumption. If one materially affects the design, say
which of the two it is and which source should settle it, ask the smallest
useful set of questions needed, and stop for my answer.

If the earlier project knowledge is sufficient, propose a system design proportionate
to this five-page marketing site.

Cover:

- page and route structure
- important component boundaries
- how page content is represented and maintained
- the contact-form submission flow
- deployment assumptions
- the high-level testing and verification approach needed by the design

This is a greenfield project, so the design also has to establish what we
build it with. For each of the following, either name a choice and say why it
fits this project, or state plainly that none is needed:

- language
- application or web framework
- rendering model
- styling approach
- component or UI approach
- animation approach
- database or other persistence
- content-management approach
- server-side runtime behaviour
- external services
- hosting and deployment model
- testing tooling
- build, lint and type-checking tooling
- package management assumptions, where relevant

Prefer the smallest set that satisfies the requirements. Do not introduce a
dependency because it is common; "none needed" is a legitimate and useful
answer where the requirements do not call for one.

Do not implement anything.

For the contact-form submission path, present two or three viable approaches.
For each, explain the consequences that matter here, including:

- external services or dependencies introduced
- operational responsibility
- cost where it materially differs
- where personal data is transmitted or stored
- relevant failure behaviour
- meaningful switching or reversal cost

Check every option against the product brief and the governing principles.
Do not present an option as viable if it violates them.

Recommend an approach and explain why, but treat the recommendation as a
proposal rather than an accepted decision.

Also identify any other proposed design choice that you believe is important
enough that its rationale should remain recoverable later. Do not create a
decision record for routine or easily understood technology choices — the
stack itself belongs in the design document, not in a record each.

Stop and wait for my decisions.

After I confirm the important choices, draft the approved design at
docs/architecture/blueprint.md and create a decision record only for each
confirmed important choice whose reason will matter to future work.

Have the approved design reference the product-brief requirements it meets, and have each decision record reference the requirement or design
section it affects, so the path from intent to implementation stays
recoverable without a separate index.

Do not change the product brief or the governing principles. If my decision
would conflict with either, flag the conflict instead of silently reconciling
it.

Inspect the current repository, then read these records for the limited
purpose of drafting agent instructions:

- docs/product/product-brief.md
- docs/governance/project-principles.md
- docs/architecture/blueprint.md
- docs/architecture/decisions/adr-001.md

Draft concise agent instructions for this walkthrough using AGENTS.md
at the repository root.

Its job is to help a coding agent navigate and work within the project,
not to become another source of product, governance, or design truth.

Include:

- how to start from the assigned work item and locate relevant project knowledge
- the repository paths future agents may need and when to consult them
- development-environment instructions that are actually established
- repository-wide implementation conventions that are actually established
- testing and required check commands that actually exist
- decision authority and stop conditions that affect an agent's work
- any established pull-request or delivery instructions
- the information a completion report should contain

Do not imply that this file grants access or decision authority that the
project rules and platform do not grant, and do not treat content the agent can read as an instruction merely
because it is accessible.

Point to sources of truth instead of copying their contents.

Do not treat reading order as an order of decision priority. Decision authority
comes from the source of truth or layer responsible for the decision,
not from reading order.

Do not invent coding conventions, required commands, repository structure,
tooling, or workflow that does not yet exist. If something has not been
established, mark it as not yet established and identify when the guidance
should be updated.

Do not review or reconcile the project records as a separate exercise. If a
missing or conflicting instruction prevents you from writing unambiguous
agent instructions, report that specific issue and identify the source that
must settle it. Do not resolve it inside AGENTS.md.

Keep AGENTS.md concise enough to function as a practical operating map rather
than a duplicate knowledge base.

Read AGENTS.md and follow its references to the sources of truth
that apply to this work.

We are preparing implementation, not changing the product brief, the governing
principles or the approved design.

First, check whether the current project knowledge is sufficient to organize the work.
If planning exposes a missing or conflicting requirement, governing principle,
system-design decision or important architectural question, say which of those
it is and which source of truth should settle it, instead of resolving it
inside the plan.

Then assess whether this project needs to be broken into more than one
implementation work item at all. Consider:

- whether there are independently meaningful outcomes
- dependencies that require sequencing
- separate risk boundaries
- separate approvers
- migration or rollout boundaries
- work that could run in parallel
- expectations that need independent verification
- whether a single change would still be reviewable
- the size and complexity of the implementation

Do not split the work by page, by technical layer, by frontend and backend, by
test type, or to reach some preferred task size. Split it only where one of the
factors above makes separate delivery genuinely better.

Recommend either a single clearly scoped work item or a sequence, and explain which
factors drove the conclusion. Flag anything too broad to review confidently,
and anything so fragmented that it no longer represents a meaningful outcome.

Do not write code or invent new requirements, architecture, or implementation
details merely to complete the plan.

Stop and wait for my confirmation of the proposed work breakdown. Do not create
the work item yet.

After I confirm the work breakdown, prepare the agreed work item or items. In
this walkthrough, record each one as a Task. A different project may already
use an issue, ticket, story or another type of work item.

Each work item should include:

- the objective
- the relevant requirement or outcome references
- relevant governing principles
- relevant approved design
- relevant decision records
- explicit in-scope and out-of-scope boundaries
- dependencies or prerequisites
- acceptance criteria
- required checks
- the evidence or completion information expected from the person or agent doing the work

Production deployment stays outside the assignee's decision authority unless it is
explicitly approved.

Reference sources of truth rather than copying them.

Do not settle new product, governing, system-design or delivery-scope
decisions inside the work item.

If required project knowledge is missing or conflicting, describe the gap and which
source of truth should settle it, rather than filling it with an
assumption.

Implement docs/delivery/tasks/task-01.md.

Follow AGENTS.md and the sources of truth referenced by the work item.

Before changing anything, inspect the current repository state. Reuse existing
patterns and conventions where they actually exist. If the project has not yet
established a relevant implementation convention, make only the local,
reversible choices needed for this work; do not invent a repository-wide rule.

Implement the bounded outcome described by Task 01, and nothing beyond it.

Do not introduce a dependency, external service, architectural boundary, or
other important design change that is not already approved by the approved
design and relevant decision records.

If the work cannot be completed without changing required product behaviour,
a governing constraint, the approved design, a delivery assumption, or
another decision outside this work item's decision authority, stop there and
report:

- what you discovered
- why the current project knowledge is insufficient or conflicting
- which existing project decision or source of truth is affected
- what work, if any, can still be completed safely within the existing scope

Add the tests and run the required checks named by the work item.

If this work establishes stable repository-wide required check commands that were
previously unknown, update or propose an update to the agent instructions before
the work is handed on for verification.

Do not deploy to production or send a live enquiry through the firm’s
production contact path.

When the bounded work is complete, report:

- what you changed
- which acceptance criteria the implementation addresses
- validation performed and its results
- evidence produced
- anything not validated or not verifiable in the current environment
- relevant assumptions or limitations
- deviations, risks, or follow-up work

Do not claim the overall work is verified or accepted. Report the evidence;
whoever assesses it will determine whether it is sufficient.

We are keeping the no-retention governing principle and changing the technical
approach.

Before writing more implementation code, reconcile the project records with
that decision.

1. Create ADR-002 for the new submission-path decision.
   Record:
   - what was discovered
   - which approved decisions or assumptions were affected
   - the viable options considered
   - their relevant consequences
   - the accepted decision and rationale
   - the requirement and design section it affects
   - that ADR-002 replaces ADR-001

   Do not delete or rewrite ADR-001.

2. Update docs/architecture/blueprint.md so the approved design reflects
   the accepted Next.js server route and transactional email API.

3. Recheck the work breakdown against the revised design. State whether it
   introduces a separate outcome, dependency, assignee, rollout boundary, or
   verification need that changes the decision to use one work item. Do not create
   a separate delivery-plan document unless the revised work genuinely needs
   one.

4. Update docs/delivery/tasks/task-01.md so its references, boundaries,
   acceptance criteria, validation, and expected evidence match the updated
   System Design and ADR-002.

5. Make the intended no-retention boundary explicit in the revised design and
   work item:
   which application, infrastructure, delivery-provider and approved receiving
   system behaviours are in scope, and what evidence Assurance will need before
   conformance can be claimed. Do not present the design choice itself as proof.

6. Check the other sources of truth for
   anything that still assumes the replaced approach. Update only the sources
   actually affected by this decision, and tell me which ones changed and which
   did not need to change.

Do not change the governing no-retention principle; that decision has been
confirmed.

If propagation reveals another missing or conflicting decision above this work,
stop again, describe the decision and the source of truth it belongs to,
and do not resolve it silently.

Once the sources of truth agree again, continue the implementation
against the updated work item. Rerun the relevant required check commands and add
the stable repository-wide commands established by this work to AGENTS.md before
handing the result to Assurance.

Verify the completed Task 01 — the whole delivered site, not only the
contact path.

Start from docs/delivery/tasks/task-01.md and follow its references to the
product brief, governing principles, approved design and
relevant accepted decision records, including the current submission-path
decision.

First identify the expectations that actually apply to this work:

- acceptance criteria in the work item
- relevant requirements from the product brief
- relevant approved design and accepted decision constraints
- relevant governing principles
- repository-wide required checks

Identify the implementation state being evaluated — for example the commit,
build, preview deployment and any important environment or
configuration state. Reuse identities already carried by continuous integration (CI) or the hosting
platform rather than duplicating them in the record.

For each expectation, determine what evidence would be sufficient to evaluate
it.

Run the relevant required check commands defined in AGENTS.md and use the
existing implementation and test evidence where it is relevant.

For expectations not established by those checks, perform additional
verification that is appropriate and possible in the current environment.
For this form, that may include relevant checks for keyboard use,
accessible labelling, error and success behaviour, narrow viewports, and the
submission and data-handling path — but only where those checks correspond to
an actual project expectation.

Do not invent a check merely because it appears in this prompt.

For each relevant requirement or acceptance criterion, record what the evidence shows:

- Verified — available evidence supports the expectation
- Failed — a required check ran and the expectation was not met
- Not verified — the available evidence is incomplete, or the check was not
  performed
- Unable to verify — verification could not be performed because a required
  environment, access, data, tool or other condition was unavailable

Use the project's own terminology if it already has one; the distinctions are
what matter. Record the failing check itself as the evidence.

State the supporting evidence for every conclusion, and distinguish evidence
from inference.

Then give an overall result — Verified, Verified with findings, Failed, Not
verified or Unable to verify.

Record important findings, residual risks, limitations, and anything that
could not be verified.

Do not describe something as verified merely because it was implemented or
because the implementation looks reasonable.

If verification exposes a gap in a requirement, a governing constraint, the
system design or the implementation, say which of those is affected and which
source of truth should settle it — do not silently change the work during
verification.

Task 01 has completed verification.

Read the current work item, VER-01, and the sources of truth it references.

First, confirm whether the verification result supports closure.

If VER-01 is Failed, Not verified, Unable to verify, or otherwise contains an
unmet requirement, acceptance criterion or required check, determine whether closure is
blocked. An exception permits closure only where project policy allows
it and the approver accepts it. Rules that allow no exceptions must still be
followed, and acceptance does not change the verification result.

Where closure is blocked, stop and identify:

- what prevents closure
- which approver is needed
- which existing project decision is unresolved, and which source of truth
  and approver should settle it

Do not treat verification as client acceptance, and do not close work unless
you are the approver or the approver has accepted it.

If the result supports closure and the required acceptance has been given,
record on Task 01 who accepted the work, the accepted build and revision, the
date, and where the original acceptance evidence is retained. Do not copy the
original correspondence into the task. Then prepare the project for its next
piece of work.

1. Confirm that the sources of truth affected by this work are
   coherent and current. Update only a source whose project knowledge
   actually changed.

2. Check that ADR-001 remains clearly replaced by ADR-002, and that the
   current approved design and Task 01 reflect the accepted submission path.

3. Confirm that the path from intent to evidence is recoverable through the
   existing references:

   product brief → system design / decision record → work item →
   implementation → verification evidence

   Do not create a central traceability table merely for closure. Recommend a shared
   traceability view only if the direct references no longer make that path
   sufficiently clear.

4. Identify follow-up work, findings, or residual concerns that should survive
   this delivery. Route each one to the existing source of truth or work
   system that owns it. Do not create a new register or backlog just for this
   walkthrough.

5. Review AGENTS.md for any lesson from this work that represents a lasting,
   repository-wide operating rule. Propose a change only if the guidance truly
   generalises. Do not add an incident-specific note.

6. Produce concise closure notes stating:
   - what was delivered
   - the verification result and supporting record
   - the approver, where this project requires one
   - important decisions that shaped the result
   - remaining findings or follow-up work
   - whether any sources of truth were updated during closure

Do not duplicate information that already has a source of truth.