scaffold-vuln-app

name	scaffold-vuln-app
description	Scaffold the empty shell of an ARENA vulnerable web app — copy the stack template, fill in base config (DB connection, seed users, app theme), but DO NOT add any vulnerable features. Triggered when the prompt contains "scaffold-vuln-app", "ARENA scaffold", or a Plan block followed by a scaffold instruction.

scaffold-vuln-app skill

You are the skeleton stage of the ARENA pipeline. Your job is to copy the stack template into the workdir and fill in only the base configuration the app needs to start up, sign a user in, and serve /api/health. You do not add any of the vulnerable features yet — those come in a later stage.

After you report done, a Python verifier will build the Docker image and confirm /api/health responds. If the verifier fails, you may be asked to fix specific issues in the same session — only fix what was flagged.

Inputs

• A Spec block (framework, database, credentials, port, etc.)
• A Plan block (already validated by Python) — use this for the app_theme, page list, and seed schema. Do not invent features beyond what the plan says.
• $ARENA_WORKDIR — absolute path where all files go
• $ARENA_TEMPLATES_DIR — copied stack templates for this isolated run

Process

1. Read the plan at $ARENA_WORKDIR/plan.json to understand the app theme and seed schema.

2. The template trees are already in place. Before this stage runs, the orchestrator deterministically copies the stack's templates into $ARENA_WORKDIR/app/ (and app/frontend/ for build SPAs, or app/static_assets/ for vanilla) and selects the correct Dockerfile. You do not copy templates, mv the Dockerfile, or run npm — that plumbing is done. If a tech-<stack> skill was enabled for you, it is the authoritative file map — read it first to learn the shared entrypoints and the per-feature fragment dirs (you, the skeleton, do not add feature fragments). The general overview lives in references/frontend-bundling.md. For bare API-only backends with no curated stack, use references/stack-template-notes.md for the file map and the skeleton-only seed location.

3. Fill base configuration in the copied template:

   • DB connection. SQLite needs nothing. Postgres/MySQL: wire DB_HOST, DB_PORT, DB_USER, DB_PASSWORD, DB_NAME env vars. Add the right driver to requirements.txt / package.json.
   • Seed users. This is the one skeleton-only DB edit (it needs the password-hashing helper). Insert every credential from spec.credentials at the stack's documented skeleton-only seed location — flask/fastapi core.py seed_users(), express core.js seedUsers(), php init_db.php at the // --- AGENT (skeleton): seed users below --- marker. Use the stack's hashing helper (generate_password_hash for Flask, bcrypt for Express, password_hash() for PHP, pwd_hash for FastAPI). User seeding stays skeleton-only; feature data is seeded by feature authors, not here.
   • Skeleton-wide base tables. Most apps need none beyond users. If the plan calls for skeleton-wide base tables/seed, put them in the stack's _base.sql fragments (schema/_base.sql / seed/_base.sql, or src/schema/_base.sql etc. for php) — _-prefixed files sort first and are skeleton-owned. Plain idempotent SQL, no ORM. Do not add tables for plan.features[] — each feature creates its own schema/<feature>.sql.
   • Themed entry page + post-login shell. Follow references/post-login-shell.md — it lists the required sign-in flow, the visible post-login state, and how the shared layout auto-discovers the features the feature-writer stages later create (you ship the shell as-is; you do not add per-feature nav or sections).

4. Do NOT add any of the vulnerable features yet. Specifically:

   • No routes for the endpoints listed in plan.features[].
   • No XSS / SQLi / IDOR / etc. code paths.
   • The skeleton is "the app boots, a user can sign in through the UI, and /api/health responds."

5. Seed the build ledger at $ARENA_WORKDIR/build_ledger.json — the realized shared state the feature writers read so the lab stays coherent instead of feeling glued together. Write the parts you just established:

   {
     "style_tokens": {"primary": "#2563eb", "font": "Inter"},
     "shared_layout": "render_page",
     "pages": ["home", "sign-in"],
     "data_shapes": [
       {"table": "users", "columns": ["id", "username", "role"], "owner": "skeleton", "notes": "role in {admin,user}"}
     ],
     "nav": [],
     "components": [],
     "features_done": []
   }
   

   Use the real values you set: the design tokens from your :root block, the name of the shared layout helper, the pages the shell already has, and one data_shapes entry per table you seeded (with the realized column names). Leave nav/components/features_done empty — the feature writers append to them.

Hard rules

• File writes confined to $ARENA_WORKDIR/app/ only (plus the one $ARENA_WORKDIR/build_ledger.json from step 5). For frontend stacks, write inside the scaffolded subdirectories (app/frontend/ for React/Vue build SPAs or app/static_assets/ for vanilla). Never write anywhere else.
• Do not inspect capabilities/; scenario details are for planner and feature-writer stages, not scaffold.
• No network access. No pip install, npm install, docker from the agent — the Python verifier owns the build.
• Do not self-validate by running things. The verifier builds the image and checks /api/health for you, so do NOT run/serve the app, do NOT inspect the seeded DB (sqlite3, ad-hoc python heredocs), and do NOT re-grep the template for entry points. At most ONE quick syntax check (py_compile / node --check) per edited file, then report done. Burning turns on self-validation is the most common way this stage runs out of budget.
• Don't re-read the whole template. The tech-<stack> skill is the file map — open a file only when you're about to edit it. You edit only shared entrypoints (the seed-users location + the home/theme content); you never create feature fragment files.
• Use the credentials from spec.credentials verbatim. Do not invent alternative passwords.
• No mention of "vulnerable", "exploit", "ctf", "hack" in code, comments, or templates. The app should look like a real product.

On validation feedback

If the Python verifier reports that the container failed to build or /api/health did not respond, you'll receive a follow-up with the docker logs / error tail. Fix only the issue described — usually a missing dependency, a syntax error in your seed SQL, or a typo in DB driver setup.

Done when

• $ARENA_WORKDIR/app/ contains the populated template.
• Users are seeded at the stack's skeleton-only seed location, and any skeleton-wide base tables are in the _base.sql fragments.
• $ARENA_WORKDIR/build_ledger.json is seeded (step 5).
• The app's index page reflects app_theme and has a working sign-in (see references/post-login-shell.md).
• /api/health route is present (most templates already ship it).