# Implementation plan template

Status: `pending_marius_confirmation`

## Orchestrator model override policy

Use this for all new project orchestration core work, especially website,
landing page, client/local-business demo, public brand page, visual product
page, app/platform planning and creative frontend work.

- Required model tier: strongest available Codex/OpenAI model.
- Current target: `gpt-5.5` high reasoning or highest configured successor/top
  model.
- Router role: safety/audit/blocker signal only; do not downroute this
  orchestrator's core work to tiny/normal coding for cost or latency.
- Router bypass/downroute override note:
- Applies to: research synthesis, visual direction, implementation planning,
  local implementation, browser QA and post-QA critique.

## Outcome

## In scope

## Not now

## Architecture decision

Include:

- default runtime choice: local/managed preview, Proxmox LXC container or
  Proxmox VM;
- why the chosen runtime is the smallest sufficient option;
- whether the iMac is useful as a worker for research/testing/builds;
- Proxmox capacity gate result when LXC/VM is chosen;
- required approval before any provider, Proxmox action outside the safe
  capacity-gated private sandbox policy, deploy, DNS, payment, email, webhook or
  live-data action.

## Data/security/privacy decision

For existing businesses, include media permission, private-demo/public-launch
boundary, privacy/cookie/form/tracking decisions and any sector compliance
checks.

## Company / client research

Use only when relevant:

- company profile:
- source log:
- media source log:
- competitor notes:
- design source map:
- design intelligence / effects recipe:
  - premium frontdesign sources inspected:
  - design diversity controls:
  - effect palette:
  - recently used styles/effects avoided:

## Visual experience / effects decision

Use for visual/client-facing projects:

- premium frontdesign source pass:
- domain object/material/process chosen as the motion metaphor:
- design dials: `DESIGN_VARIANCE`, `MOTION_INTENSITY`, `VISUAL_DENSITY`:
- recently used styles/effects to avoid:
- effect palette: hero metaphor, typography reveal, card motion, navigation
  motion and media treatment:
- why it fits the business category and audience:
- scroll story chapters from hero to contact/footer:
- how menu/navigation, section text, product/service cards, galleries and CTAs
  participate in the same motion language:
- reduced-motion fallback:
- what to avoid because it hurts readability, performance or task completion:

## Visual concept gate

Concrete gate file: `plan/visual-concept-gate.md`.

- Gate status:
- Model route evidence:
- Concept artifacts or references:
- Marius acceptance:
- Exemption reason, if any:

Do not implement while the visual concept gate is `pending`. A template-only
plan is not enough for local implementation.

## Scroll-film implementation contract

Required for emotional client-facing demos unless Marius explicitly approves a
speed-first/static downgrade or this is an admin/operational surface. A generic
static hero plus repeated cards is not enough for an impressive local-business
demo.

- Long sticky/pinned hero or story stage:
- Native scroll progress variable/state:
- Domain object/material/process as moving frame, mask, portal, cutaway or
  foreground anchor:
- Chapter/progress markers:
- Scroll-tied image transforms:
- Scroll-tied text transforms:
- Menu/navigation participation:
- Product/service cards, gallery, CTA/contact and footer participation:
- `prefers-reduced-motion` fallback:
- Desktop/mobile QA checkpoints at 0%, 25%, 50%, 75% and 100% scroll:
- Evidence that transforms/opacity/blur/clip-path actually change:
- Reason for exemption, if any:

## Runtime placement decision

Options:

- `local_or_managed_preview`: default for small sites, demos and static-first
  apps.
- `proxmox_lxc_container`: use only for justified small always-on internal
  services, staging APIs, workers or repeatable sandboxes.
- `proxmox_vm`: use only for strong isolation, OS/kernel needs, risky
  dependencies, multi-service labs, client-data separation or rollback boundary.

Before Proxmox work:

- run read-only health/status checks;
- estimate CPU/RAM/disk/network impact;
- run the capacity gate:

```bash
/Users/mariusfit/.codex/tools/codex-proxmox-snapshot/codex_proxmox_snapshot.py --capacity-check --kind <lxc|vm> --memory-gib <n> --disk-gib <n> --vcpus <n> --json
```

- define rollback/snapshot plan;
- if the gate passes, Marius's standing approval covers private sandbox
  creation;
- ask Marius only when the gate blocks, safe caps are exceeded, health is
  unclear, public exposure is needed, or existing/destructive infrastructure is
  changed.

## Documentation plan

## Testing plan

Use small/medium/large scope:

- Small: fast local unit/contract/schema checks.
- Medium: integration/API/component checks.
- Large: browser/E2E/manual or deployed-environment checks.

For visual/client-facing projects, include screenshot QA against the chosen
effects recipe: desktop, mobile, motion/reduced-motion where relevant, color
contrast/readability, image treatment, no overlap/clipping and no effect that
hurts the primary task. For cinematic scroll pages, add checkpoints for the
hero object/metaphor, text-over-image reveal, menu/navigation state,
mid-page cards/sections, CTA/contact and final mobile layout.
For scroll-film pages, verify 0%, 25%, 50%, 75% and 100% scroll positions on
desktop and mobile and confirm computed transform/opacity/filter/clip-path or
CSS-variable values change as expected.

## Autonomous task queue

Each task must include:

- task id;
- scope;
- files/modules owned;
- validation to run;
- documentation to update;
- stop conditions.

Stop immediately if the next step requires unapproved provider accounts,
secrets, real client data, production DNS/deploy, payments, email/webhooks,
Proxmox guest creation/change outside the safe capacity-gated sandbox policy,
social scraping or legal permission.

## Marius confirmation

Implementation must not start until Marius explicitly approves this concrete
plan and the visual concept gate is accepted, ready, explicitly exempted by
Marius, or marked not applicable for nonvisual work.

After Marius confirms, record approval with:

```bash
/Users/mariusfit/.codex/hooks/new-project-research-orchestrator.sh approve --project-dir docs/project-intake/<this-dir> --scope localImplementation
```