Agent instructions

Read /home/jason/.codex/RTK.md.

#Delivery discipline

#Current user direction: Dusk identity rename complete — 5/5, stop

• Delivered on codex/dusk-identity; PR https://github.com/jasona/dusk-engine/pull/2 is open to main. Do not merge, deploy or start new scope without a user decision.

• October 28: the user asked to implement llm-docs/DUSK_IDENTITY_AND_REFERENCE_GAME_PLAN.md. Dusk is the engine; Darkwind is the reference game built with Dusk. Work on codex/dusk-identity through the five fixed milestones R1–R5 in order, reporting the rename counter (n/5) separately from feature implementation (70/70) and polish (5/5).

• Classify every old-name occurrence before changing it, using docs/DUSK_COMPATIBILITY.md. Keep serialized identifiers, storage keys, volumes, database names and Darkwind game identity. The goal is correct ownership, not zero matches.

• External operations (GitHub repository rename, default branch, Coolify resources, deployment) are not authorized by this direction. Prepare them and record their status; do not perform them.

• Stop after R5 and its PR. Do not resume the art, benchmark or diagnostics backlog.

#Earlier direction: fixed polish pass complete — stop at 5/5

• Completion: all five milestones are delivered; the physical-GPU continuous two-traveler house/garden/cart/house journey passes. Feature implementation is 70/70; polish is 5/5. Preserve this finish line and stop. Do not choose further polish, diagnostics, optimization or tests from the historical backlog without a new user scope decision. See the current block in ENGINE_PROGRESS and the acceptance record in TRAVELER_ART. Docker acceptance remains separate and awaits the user's result for the exact tested commit.

• October 28: the user explicitly authorized the proposed polish pass and asked to work until done. Complete these fixed milestones in order: P1 garden atmosphere/planting; P2 character motion/presence using the approved model; P3 interior materials/light/contact; P4 cart wheel/steering/seat presentation; P5 HUD readability and interaction feedback. Commit/push each usable milestone, post the actual visual, and report polish progress as 1/5 through 5/5 separately from feature implementation (70/70). Finish with matching before/after views, a short motion recording and the fixed shared house/garden/cart/house journey. Stop at 5/5; record further findings for follow-up. No benchmark campaign, expanded regression matrix, new character direction or feature scope is part of this pass. Existing Docker acceptance is separate and still awaits the user's result; do not claim it passed.

#Earlier beta qualification — separate Docker handoff

• Current state after gate-4 closure: 4/5 beta gates closed, feature implementation 70/70. Candidate 0546627 is pushed. Only gate 5 remains: the existing arrival-art Docker smoke and final handoff. Docker daemon access is unavailable here; the user has been asked to run the pinned check or enable access. Do not repeat passed database/visual/benchmark work or fill this external wait with optional tasks. If Docker exposes a packaging failure, fix it within gate 5. After that smoke passes, record the result, hand over the candidate and stop this pass. See the current block in docs/ENGINE_PROGRESS.md.

• October 28 stopping-rule correction: use the five frozen beta release gates in docs/RELEASE_CANDIDATE.md. Gate 4 (database regression) is now closed; gate 5 (Docker smoke and final pinned handoff) is the sole active gate. Do not expand the pass with more benchmarking, art revisions, diagnostic campaigns or optional optimization. Record new nonblocking findings in follow-up notes. After all five gates close, stop and hand over the build. Report unavailable external access as a blocker with its exact remaining step; do not call it passed or fill the time with unrelated work. Further scope needs an explicit user decision. Preserve the separate full-roadmap qualification requirements and the fixed 70/70 feature counter.

• October 28: the user requested testing, benchmarks and final visual polish. Feature implementation remains 70/70 (100%). Run the integrated regression and production build, measure the named workloads, fix demonstrated failures, and deliver visible polish with screenshots. Keep qualification results separate from the fixed feature counter. Preserve the approved Vita character direction.

#Earlier delivery direction

• Latest instruction: commit/push the complete current work to https://github.com/jasona/awaken-engine.git, then finish F65, F66, F53, F13, F69 and F70. Push every milestone on codex/engine-foundations and report the fixed feature counter. Broader testing and optimization follow feature completion.

• October 27 correction: report feature implementation using the frozen 70-item inventory in docs/FEATURE_COMPLETION.md (64 implemented, six open at the audit). Testing, coverage, performance, deployment qualification and final polish are separate; they must not reduce this feature percentage. Finish the six named functional gaps before broader testing/optimization. Keep the denominator fixed unless the user explicitly changes scope. The prior 80% answer was terrain-only, not the overall feature-completion percentage.

• Latest user direction: commit and push ready increments, then prioritize substantive missing core engine capabilities. Do not spend successive turns on small optimizations; retain failed performance gates for final qualification.

• User correction: stop extending recording conveniences while core roadmap implementation remains unfinished. Prioritize substantive missing engine capabilities and report honest, uncertain progress; the earlier 98% estimate was too optimistic. Recording still requires final authoritative replay work.

• Ship working, usable increments after focused checks. Do not hold each increment for exhaustive testing, repeated hardware/software runs or minor polish.

• Fix demonstrated blockers to using the feature. Record nonblocking defects, unverified cases, broader regression/performance checks and polish in the feature's existing documentation, then continue implementing the plan.

• Commit and push usable increments to codex/engine-foundations promptly. Report the commit, what the user can try and the remaining review items.

• Keep full-plan acceptance gates for the final qualification pass. Deferred checks are unfinished work, not evidence of completion. Preserve the required final character/environment art pass and report approximate progress honestly.

• This direction supersedes the older per-increment verification cadence below.

These instructions record the user's correction after repeated small diagnostic increments displaced visible feature delivery. Apply them on every continuation, including after context compaction.

• Read the Current delivery milestone in docs/ENGINE_PROGRESS.md before choosing work. Keep one feature milestone active until its stated acceptance conditions are met or a concrete blocker requires a different task.
• Advance the feature through authoring, persistence, shared play and presentation where applicable. Do not replace the full engine objective with a smaller goal.
• Reliability work belongs in the active feature when it resolves a demonstrated blocker. Do not start unrelated diagnostic campaigns or polish internal tools while the active user-facing feature is unfinished.
• Use focused checks during implementation. Run the necessary broader regression checks at the integration milestone. Rerun a passed check only when changed code, a failure or a specific unresolved risk justifies it. Keep required gates intact.
• Visually review visible features before declaring them ready. Preserve the required final character/environment/arrival art pass. The user approved the current white-haired fantasy character on October 27; preserve that choice.
• Keep one concise acceptance record per delivered feature. Retain useful failure details, commands and screenshots, but do not routinely commit duplicate raw logs, full report dumps or separate evidence dossiers for tiny adjustments.
• At a verified delivery milestone, report what the user can now do, how to try it, relevant validation, remaining limitations and the approximate full-plan percent. Include a screenshot of the actual result at each milestone when possible; if no meaningful screenshot is available, say so instead of substituting unrelated art. Percent is a rough scope estimate, not measured completion. Do not raise it for bookkeeping or imply that it proves a numbered roadmap milestone is complete.
• Update the current milestone block when the feature is delivered. Do not let historical progress entries become the next-task selection mechanism.

Continue existing authorization for development, tests, commits and pushes to codex/engine-foundations. Do not merge main or deploy production without the required authorization. Use parallel agents only when explicitly authorized by the user; these instructions do not authorize delegation.