Enter Project Ops

Enter Project Ops

Build and operate Enter projects with a strict division of labor: Enter is the executor, you are the planner and the independent verifier. Enter's completion message is an implementation claim, never test evidence. Everything worth shipping is proven from outside Enter.

Read On Demand

• Read acceptance-matrix.md before any visual/responsive/runtime regression pass.
• Read change-prompt.md before submitting anything through the Enter chat — creation prompts and bounded change prompts both.
• Read platform-playbook.md before your first editor session of the day, and any time the platform behaves strangely — it catalogs the quirks that are normal.
• Apply browser-ops for login, session ownership, screenshots, and side-effect authorization.

The Mental Model

Enter is strong at execution and honest in its receipts (it reports bugs it found and fixed itself). It is still a single lane: its "done" message, its in-editor lint/build, and its own screenshots are all the same system grading its own homework. Your job is the second lane.

Guardrails

• Bind every action to the exact Enter project ID, chat ID, editor URL, and preview URL. Record them before the first prompt.
• Approval to optimize authorizes bounded edits and their verification. It does not authorize 发布 (publish), sharing as template, cover/asset generation, deletion, billing, another project, or another environment. Publishing is a separate, explicit authorization, every time.
• Never expose cookies, tokens, storage state, or account data. Save login state only to a secrets directory with 600 permissions, outside any repo.
• Separate product defects from platform noise. A stale task stream, a hot-update flicker, or a deploy-propagation delay is not a product bug — verify against a fresh preview load.
• Preserve user tabs and shared browser services. Close only task-owned isolated tabs or contexts.

Workflow

0. Write The Contract First

Before touching the editor, write a local contract file (markdown) and keep it updated as the run log:

• Target: project ID, chat ID, editor URL, preview URL (fill in after creation).
• Concept: what the thing is, who it's for, the one-sentence demo story.
• Capability showcase: which platform abilities this project demonstrates (streaming, persistence, RLS, external data, etc.).
• Guardrails: what is never allowed without separate authorization (publish, share, assets, keys client-side…).
• Run log: one row per round — action, independent verification, result, evidence paths.

This file is what survives context compaction and session resets. Enter has its own memory; yours is this file.

1. Create (Greenfield)

1. Submit one rich creation prompt (see change-prompt.md). A good creation prompt fixes: concept, data sources, refresh/cost model, storage + access semantics, page structure, and the constraints (keys server-side, graceful degradation, no publish, viewports).
2. Answer Enter's clarifying questions only within the authorized scope. Model-choice cards, cloud-instance creation, and AI-capability enablement are normal gates — pick deliberately, they're part of the build.
3. If Enter returns a plan instead of building: inspect scope and files, then click 立即构建 only when the plan stays inside the authorized target.
4. Expect a long build (tens of operations). Monitor per platform-playbook.md — task streams go stale, reload the editor URL to resync.

2. Capture A Baseline

Two lanes, always:

Visual lane — render at 1440x900, 390x844, 327x603; first fold and full page; exercise the defining interaction; check hierarchy, overflow, touch targets, motion.

Independent health lane — isolated Playwright (no extensions): DOM assertions, console, network, broken images, exact overflow metrics. Plus the lanes Enter can't fake:

• Data lane: if the project uses Enter Cloud with public-read tables, query the REST endpoint directly with the public anon key and compare against what the UI claims. The database is the strongest source of truth.
• Stream lane: for streaming features, witness a live generation once — don't only verify the completed state.
• Clipboard lane: read the OS clipboard (e.g. pbpaste) after copy interactions; in-page readText() hangs on permission prompts.

Use acceptance-matrix.md as the checklist.

3. Iterate In Bounded Batches

Never send a mega-prompt. Decompose a big mandate ("do everything") into cohesive batches, each:

• one theme (e.g. "radar-ize the leaderboard", "multi-source", "weekly digest");
• with fresh baseline evidence, explicit invariants that must not regress, explicit exclusions, and a required receipt format;
• independently verified before the next batch starts.

Enter's own discipline compounds: each batch's receipt becomes the next batch's baseline. Two to six batches per project is the healthy range we've battle-tested.

4. Verify Each Batch

1. Reopen the live preview fresh after Enter's receipt (deploy propagation lags — see playbook).
2. Re-run the failing case first, then the full matrix.
3. Confirm the revision actually changed (fresh content, new fields in the data lane).
4. Check backward compatibility explicitly: old data/rows/states must still render.
5. Update the contract run log with evidence paths.

5. Publish — Only On Explicit Authorization

Publishing is a distinct act with its own verification: prod URL, fresh load, viewports, console. Never infer it from "make it good" or from a previous project's publish approval.

Closeout

Report: exact project and final preview URL, what changed per batch, fresh evidence, files created/updated, what was intentionally not done (publish, share, assets), and residual risk. Reset temporary viewport overrides. Update the contract file's run log — it's the next session's memory.