# Shrine Approach — build task **This task lives at `~/Documents/shrine-approach-unity.v1/`.** Every relative path below is relative to that folder. Read this whole file before doing anything. Build a **walkable third-person night scene** of a Japanese shrine approach in Unity, matching the approved concept art. The player walks a stone-paved approach through a vermilion torii, up worn steps, to a lantern-lit haiden inside a walled precinct. Scope is deliberately small: **one precinct, roughly 60–70 m gate to sanctuary.** No village street, no combat, no quest. Walking through a beautiful place is the entire deliverable. **Run mode: `r_and_d`.** Lock it in the run contract before you start. ## The bar This is a max-effort build. Within that small scope, **every single thing should be done to the standard of the concept art** — textures, materials, lighting, silhouettes, the way light pools on wet stone, moss in the joints of the steps, vines on the torii, mist between the trunks, the character's weight as he walks. Anything visible should look considered. Sweat the details nobody asked about. The referent is not a mood board, it is the bar. Go and look at it again now, properly, before you write any code — and keep going back to it. Every time you are tempted to call something finished, put your frame beside the hero shot and ask what a senior environment artist would say about the difference. **Ambition applies to quality, never to scope.** Do not add a village, a quest, enemies, or systems nobody asked for. More features is the wrong direction; more care within these 60 metres is the right one. A small place built beautifully beats a large place built adequately, and the second one is much easier to accidentally produce. --- ## Read first The pipeline at `~/Documents/remakebench-harness/pipeline/` carries all the reliability engineering — setup, invariants, the phase template, the art-direction judge, and the validator. Read `README.md` and follow `SKELETON.md`. When something breaks, `SYMPTOMS.md` is indexed by what you observe. Everything in `INVARIANTS.md` was paid for with a real defect; you do not need to rediscover any of it. Start with `python3 ~/Documents/remakebench-harness/pipeline/doctor.py`. **Blender MCP is currently disconnected** — either restart its server, or author headless with `blender --background`, which is what `INVARIANTS.md` recommends for heavy authoring anyway. ## Given — do not regenerate **The character is fixed.** `~/Documents/samurai-character/export/Character/` ``` SamuraiBody.fbx rigged, 53 bones, bind pose Animations/ Idle · Walk · Run · Unsheath · Sheath · Attack Equipment/ Katana.fbx (pivot at grip) · Saya.fbx (pivot at koiguchi) Materials/ base_color · normal · roughness · metallic · emission ``` Sockets are already on the rig: `SOCKET_katana` on `hand.R`, `SOCKET_saya` on `spine_03`. Read `~/Documents/samurai-character/README.md` and `LESSONS.md` before importing — they document the rig's conventions. **No Meshy character generation, no auto-rig, no stock animation.** Idle, Walk and Run are all the traversal needs; Unsheath and Sheath are yours to use for flavour if you want. **Phase 3 and Phase 3.5 of the skeleton are already satisfied by this character.** It is rigged, its equipment is already separate rigid meshes with correct pivots, and its sockets are already calibrated on the rig. Do not re-derive any of it — import, verify the sockets hold in play mode, and move on. If something about the rig genuinely doesn't work, report it rather than rebuilding it. That means **Meshy is only needed for tileable textures** (`text_to_image`, 3 credits each) and, at most, one sculptural prop. Everything structural is authored Blender geometry. ## The referent — pinned, hashed, and what the judge scores against **`~/Documents/shrine-approach-unity.v1/reference/`**. Five images. Open every one of them before you write code — actually open them, do not work from this table's descriptions. | File | What it is | |---|---| | `A_hero_view.png` | **The primary target.** Eye-level, up the approach through the torii. This is the frame the judge compares against | | `B_overview_aerial.png` | Aerial of the whole precinct — layout, extent, where the wall runs | | `C_sheet_a_hero_reverse_overview.png` | Hero, reverse and overview panels together | | `D_sheet_b_elevations_details_materials.png` | **Orthographic FRONT and SIDE elevations of the haiden** — proportions, roof pitch, raised platform, railing, step entry. Plus eave, paving, lantern-and-steps details and the materials panel | | `E_detail_eave_paving_materials.png` | The same details at native resolution — use these for close work | Verify them before you start and again before you report: ```bash cd ~/Documents/shrine-approach-unity.v1/reference && shasum -a 256 -c SHA256SUMS ``` **`D_` is what you build the haiden from.** Those elevations are the clearest structural reference in the set — take the shrine's proportions, roof pitch, platform height and railing from there rather than guessing off the hero shot's perspective. **`C_`'s SITE PLAN panel is legible and is your layout.** Read off it directly: - a rectangular walled precinct with trees ringing the outside of the wall - a central paved path running the long axis, torii at the entrance end - **paired stone lanterns down both sides of the path** at regular intervals - **four subsidiary buildings flanking the path**, two per side, tile-roofed - the haiden at the far end on a raised platform, reached by a stair It carries no dimensions — metres come from this document — but the arrangement is authoritative. Also note from `C_`'s REVERSE VIEW: there is a **second, smaller torii** further down the approach. Two gates, not one. **Your texture list is the materials panel, and it is exactly four families:** dark weathered timber, cream plaster, grey ceramic roof tile, mossy stone. The four props are stone lantern, stone water basin, ceramic jar, plain indigo noren. That panel is deliberately lit in neutral daylight while every other panel is night, because a material swatch rendered in the dark is useless as a brief — do not "fix" it. ## What the target actually demands Study the hero shot before writing any code. The things that make it work, and that a build typically misses: - **Genuine blacks.** Shadows go to near-zero. This is the failure mode that has cost the most on previous builds — see `FINDINGS/2026-07-28-albedo-is-the-floor.md` before you touch a light. - **Wet stone.** Lantern light reflecting down the paving is doing half the work in that image. - **Cool moonlight key against warm flame fill**, and nothing else lighting the scene. - **Density.** Lanterns, moss, fallen leaves, undergrowth, vines on the torii. Empty ground reads as unfinished. - Mist between the trunks, and a moon behind thin cloud. ## Constraints - 1 unit = 1 metre. The samurai is your scale reference — everything is checked against him. - **Minimum 150k triangles** for the environment. That is a floor, not a ceiling. - **Structure, from the site plan:** outer torii, inner torii, central paved path, **four tile-roofed subsidiary buildings flanking the path (two per side)**, precinct wall on all sides, stone stair, haiden on a raised platform. - **Prop manifest, minimum counts:** ≥ 20 stone lanterns *paired down both sides of the path*, ≥ 8 trees ringing the outside of the wall, ≥ 30 undergrowth/shrub clusters, ≥ 12 moss/leaf-litter patches, ≥ 4 precinct wall sections with tiled caps, plus the four props named in the materials panel: stone lantern, stone water basin, ceramic jar, indigo noren. - Prefix meshes `WALK_` / `COL_` / `NOCOL_`. `COL_` means volumetric blocker only. - Set anti-aliasing in Phase 0, before any capture. - Third-person orbit camera with wall collision. Walk, run, and turn using the given clips. ## The judge decides when you are done Follow `JUDGE.md` exactly. **Spawn a separate subagent as the judge.** Not you re-reading your own screenshot in a critical voice — an actual spawned agent that receives only the capture, the referent images, and the judge prompt. No build history, no logs, no explanation of what you tried or how hard it was. A scorecard produced without spawning anything is not a judge round. It scores your **locked play-mode capture** against the hero shot, and **you do not get to declare the work finished.** In `r_and_d` mode you iterate until it passes or the operator stops you. **Expect this to take many hours.** The failure mode here is stopping early because things look broadly right; the whole point of the judge is that "broadly right" is not the bar. If you find yourself finishing quickly, you have almost certainly stopped short of what the referent demands — go back and compare them side by side again. ### Partition the work across subagents — but only where the interface is clean Give each of these its own subagent, its own numeric gate, and its own loop. **Each one keeps iterating until its gate passes**, without waiting on the others: | Subagent | Gate it loops against | |---|---| | Tileable textures | local contrast ≥ 12 or relative ≥ 0.30, seam ≤ 0.06, per texture | | Precinct structure — walls, torii, steps, haiden | ≥ 150k triangles, metric scale, zero unprefixed meshes | | Dressing props — lanterns, trees, undergrowth, moss | the prop manifest counts, all met | | Character integration | play-mode capture, clips firing, proven by accumulated joint rotation | | Audio | clip count equals distinct line count | **Do not partition the art direction itself.** Lighting, value range, fog and the post-processing grade are a single global property — one agent owns them, start to finish. Split across agents they will fight each other, and you will get a scene that is lit four different ways. Every parallel agent works to the **same art bible**. Hand each one the referent images, not a paraphrase of them — a description of a look is where drift starts. The judge stays separate from all of them and sees only the finished frame. ### Run the judge cycle as an actual loop **build → capture → spawn judge → apply the fix list → rebuild → spawn judge again**, and do not exit that cycle on your own judgement. Use whatever looping mechanism you have: | If you are | Use | |---|---| | Claude Code | `/loop` on the judge cycle — omit the interval to self-pace | | Kimi CLI | Ralph loop, `--max-ralph-iterations` | | Gemini CLI | the Ralph extension, `/ralph:loop` | | OpenCode | `opencode-loop` | | Codex or anything else | wrap it yourself — a shell loop around the build-and-judge step, or just keep iterating and do not stop | If you have none of these, the loop is still the requirement; it is simply manual. **The exit condition is the judge passing or the operator stopping you — never your own assessment that it looks good enough.** Lock the judge camera before you build — eye height 1.65 m, standing on the approach below the torii, looking up toward the haiden — record the transform, and never move it. All acceptance measurement happens in **play mode**. Editor captures render a frame the player never sees; the difference was measured at 8×. Run `validate.py` alongside the judge. The judge grades art direction from one frame; the validator grades everything mechanical. Neither substitutes for the other. ## Report Follow the reporting contract in `SKELETON.md` Phase 7. End with **anything you faked** — every substitution, placeholder, partially-met requirement, and every time the operator steered you. A truthful partial failure is useful evidence. A green report hiding a substitution is not.