aetherbound-guild/AGENTS.md

Aetherbound Guild Agent Contract

This file narrows the portfolio rules for this repository.

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/.

• 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

Phase 8 design is Owner-accepted. Phase 9 Godot vertical-slice development is authorized only through the active Goal named by CURRENT_CHECKPOINT.md. Runtime source belongs under runtime/; accepted HTML design authority remains under prototype/ and may not be silently rewritten to fit implementation. P9.0R3 is the Owner-accepted baseline for tutorial-battle pacing and event-bound combat feedback inside the preserved Title -> Guild Yard -> tutorial battle -> victory flow. Its source is frozen. P9.0R4 remains the preserved two-battle preview baseline. P9.0R5 is the Owner-accepted complete first-session baseline through Guild choice, third battle and session result. P9.0R6 is the preserved route-decision baseline. P9.0R7 is the preserved individual-growth H5 baseline. P9.0R8 is the preserved front-door H5 baseline. P9.0R9 is a preserved first-Company H5 baseline whose separate front/rear selection was rejected by Owner review. P9.0R9A is the preserved automatic- formation baseline: the player chooses any two of four Recruits and the system orders them. P9.0R10 is the preserved six-pair compatibility baseline. P9.1 is the active runtime milestone: carry every legal starting pair through the complete five-battle first-session shape, while first extracting modular runtime boundaries so parallel developers do not concurrently edit runtime/main.gd. P9.1 begins with a specification-only expert wave; implementation opens only after game-design, UX/visual and technical-architecture outputs are reconciled into one frozen contract. Contract, difficulty, authoritative XP/levels three through ten, promotion, formal Market/permanent equipment inventory, Party order, casualty/recovery, authoritative combat, persistence, chapters, device packaging, stores and release remain frozen.

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:

1. Product and player-experience contract.
2. Core loop, battle, profession, skill, progression, economy, failure, save, difficulty, and postgame specifications.
3. 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.
4. Complete screen/state map, onboarding, accessibility, localization, input, error, empty, confirmation, settings, and endgame states.
5. Art direction, asset inventory, animation matrix, VFX language, music plan, and SFX event catalog.
6. Landscape HTML design gallery showing every player-facing page and key state.
7. Economy/build simulations and a decision-density audit.
8. 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.