11 KiB
Aetherbound Guild Agent Contract
This file narrows the portfolio rules for this repository.
Aetherbound Visual Direction Override
The portfolio-level pixel-art production rule does not apply to Aetherbound Guild. This repository's Owner-approved product authority is an original landscape Japanese 2D hand-drawn fantasy presentation:
- ally battle character language and identity come from the accepted M69
soft-Q (
q_pf_b01..12) family and stay consistent across the battle field, bottom Company rail, opening and knockout/result surfaces; the thin-line, cel-color treatment remains this repository's Japanese 2D hand-drawn direction, and every actor stays readable at actual play size; - softly painted environments with editable depth layers;
- ordinary battle units sized to preserve the complete Company line, enemy relation and movement corridor, with final scale confirmed by the Owner from a real runtime frame;
- compact field-attached HUD chrome rather than a card wall; and
- engine-rendered text and values over non-pixel runtime art.
The 05_battle_ui_japanese_scale.png file under
docs/prototype/generation/phase6_ui_direction_01/outputs/ is the accepted
composition, corridor, ally/enemy relation and scale-review authority. It does
not override the M69 soft-Q allied character language above. An early Company
line shows only the actual active roster; never pad it with invented units.
Internal proportion bands (for example the 0.12–0.30 actor-height proxy) are
measurement proxies only, not an accepted scale, until the Owner confirms a
real runtime frame.
docs/01_GAME_DESIGN.md and docs/04_ART_ANIMATION_AUDIO.md remain the
product and style authority. Pixel
art, nearest-neighbor conversion, low-resolution palette reduction and
post-process pixelation are prohibited for final Aetherbound presentation.
Existing pixel runtime assets are rejected historical candidates: preserve
their provenance, but do not expand or treat them as accepted visual authority.
UI Restoration Memory (mandatory)
When implementing or restoring any page from a design image, treat the image as a measured composition contract, not as a mood reference and not as a collection of approximate coordinates. Before changing page code, record the design canvas ratio, safe margins, every component's authored bounds, and the runtime text/icon slots. A page is not ready for review until those slots are used by the implementation.
- Separate
static_master,runtime_content, andhit_area_onlyownership for every visible region. Never draw a second frame, badge, icon or warning over an authored surface. - Every reusable component must declare: source asset, intrinsic dimensions, alpha/background treatment, nine-patch or fixed-aspect policy, edge/center margins, minimum play-size bounds, text slots, icon slots, contrast pair and state variants. Generated whole-silhouette art must not be sent directly through NinePatch until its edge/center slices are validated.
- Dynamic states receive separate layouts when their information architecture
differs (
empty,selected,disabled,loading,error). Do not force an empty state through a selected-state template. - Text, prices, names and state values are always engine-rendered. Test actual localized strings inside their authored slots; no label may leave its owner surface, overlap a neighbor or become unreadable against the material.
- Use a centered design canvas for geometry, aspect-cover only for the world background, and fixed-size inner type/icons with adaptive outer spacing. Do not solve overflow by shrinking type below its token or hiding content.
- Before claiming visual progress, capture and inspect static-only, dynamic-only on neutral background, and final composite views at the minimum, reference and wide viewports in every shipped locale. Behavior and node-existence tests cannot substitute for visual inspection.
- Identify the earliest failed boundary in this order:
base image -> aspect/crop -> ownership -> layer alignment -> subject scale -> text slot -> overflow/contrast -> interaction bounds. Repair that boundary before adding polish or migrating another page. - A page-local
StyleBoxFlat, ad-hoc color, or text-only button is prohibited when a shared token/component exists. New visual rules belong in the shared UI layer and must be recorded indocs/runtime/M52_SHARED_UI_RULES.md(or its successor) before reuse on another page. - Passing automated tests is only a machine gate. The current revision remains
OPENuntil the agent has inspected normal renders and the owner has reviewed the intended page at play size.
Plan-Driven Development
Every non-trivial implementation milestone must have one active durable plan
before product code changes continue. The active plan is named by
CURRENT_CHECKPOINT.md and lives beside the milestone contract under docs/.
This repository contract contains the mandatory planning and execution process.
- The plan must define the player-visible stopping point, ordered steps, acceptance checks, frozen scope, commit boundaries and final handoff.
- Exactly one step may be
IN_PROGRESS. Code changes must belong to that step. New findings are recorded in the plan's issue register and do not silently expand the active step. - Finish the narrowest focused verification and create a focused pushed commit
before changing the next step to
IN_PROGRESS. - Update the plan and checkpoint after an actual status change, not after every command. Chat summaries never replace the durable status.
- A failed check keeps the same step active. Repair the earliest failed product boundary; do not skip ahead, loosen the check or start unrelated polish.
- Packaging, deployment and release remain separate steps and require the owner's explicit authorization even when they appear in a future plan.
- A milestone ends at its written stopping point. Further systems require a new plan or an explicit revision approved by the owner.
Current Stage
The entry-first redevelopment order recorded by DEV-1 is completed history:
real Godot boot, first-launch setup, Title and essential Settings are reachable
in player order, and the later named steps (new-run selection, Guild, Market,
automatic formation, risk, battle, result and continuation) are implemented and
verified through the first-cycle route. DEV-1 is no longer the only current
first step and must not be cited as a freeze on later work.
Active work is always the durable plan named by CURRENT_CHECKPOINT.md; this
section must not become a milestone pointer. As completed history, on
2026-09-23 M108 completed the A1/B1/D1 authority and evidence-claims
alignment. M107 closed only at
the evidence-machine boundary: it proves evidence truthfulness and fixture
gates, not that the UI or the product has no defects. Owner comprehension,
feel, listening, device and final-art gates remain OPEN, and no document may
claim ABG MVP QUALITY READY before the Owner records those decisions.
Gameplay, economy, content, Save and audio semantics remain unchanged until a named step authorizes them. No historical Phase, Goal, test attempt or H5 document is current authority merely because it still exists in Git history.
Test Attempt Hygiene
- Fresh Git archive/import, capture, MovieWriter, Web and Playwright evidence
commands must run through
tools/run_test_attempt.pyunless the active Goal names a stricter checked-in runner. The command owns one source/HOME/cache/ TMP/browser root and removes it after archiving compact evidence on success, failure, timeout or handled interruption. - The attempt runner must block handled termination signals while it creates and marks the owned root, then restore delivery only after its cleanup guard is active. A signal during startup is not permission to leave an unowned or half-initialized source/import root behind.
- Cleanup owns the complete child process group, not only the immediate shell. After timeout or interruption it must TERM, wait, KILL only if required, and retry removal after browser writers exit before recording the terminal.
- A zero child exit is not sufficient. Godot/runtime diagnostics remain strict,
and formal calls must pass each expected terminal with
--require-marker; every required marker must appear exactly once before the runner records PASS. - Test commands write retained artifacts only below
ABG_EVIDENCE_DIR. Do not place source archives, Godot import caches, browser profiles, raw Chrome code-signing copies or temporary HOME directories there. - The default retention ceiling is three unprotected passed attempts and three
unprotected failed attempts per label.
FAIL,TIMEOUT,INTERRUPTEDandHARNESS_ERRORshare the same failed-attempt ceiling. Every terminal remains in the compact append-onlyattempts.jsonljournal. - A retained attempt referenced by tracked authority or marked with
.keepis protected from runner pruning. Never use the runner to delete older evidence roots created outside its own artifact family. - Repository Playwright checks must install
tools/browser_temp.jsbefore requiring Playwright. It confines Chrome profiles/artifacts/signing copies to an owned root, cleans normal/signal exits and removes stale owned roots on the next invocation.
Originality Boundary
- Authorized private reference material may be inspected only to identify systems, player decisions, content categories, pacing patterns, and production scope.
- Do not copy reference names, prose, formulas, layouts, progression trees, source code, art, music, sound effects, or other expressive assets.
- Do not place third-party commercial assets in this repository.
- Every product-facing design must be independently authored and traceable to this game's approved product contract.
Design Completion Gate
Formal development remains frozen until all of these are complete, mutually consistent, independently reviewed, and owner-approved:
- Product and player-experience contract.
- Core loop, battle, profession, skill, progression, economy, failure, save, difficulty, and postgame specifications.
- Complete generated-recruit rules; 12 base, 24 advanced, and 6 hidden professions; 36 mechanical traits; 320 equipment items; 60 artifacts; 100 ordinary/elite enemies; 16 bosses; and 8 regions, with no filler rows. Recruits are not fixed story protagonists and do not require relationship, affinity, romance, personal-arc, or individual voice-content systems.
- Complete screen/state map, onboarding, accessibility, localization, input, error, empty, confirmation, settings, and endgame states.
- Art direction, asset inventory, animation matrix, VFX language, music plan, and SFX event catalog.
- Landscape HTML design gallery showing every player-facing page and key state.
- Economy/build simulations and a decision-density audit.
- Interactive design prototype and owner review.
Owner visual/feel acceptance applies only to the bounded P9.0R3 tutorial battle presentation. Human listening, broader comprehension/fun, device, packaging, store, and release acceptance remain separate gates. P9.0R3 does not authorize the later authoritative battle system.