94 lines
5.2 KiB
Markdown
94 lines
5.2 KiB
Markdown
# 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 mandatory repository process is
|
|
`docs/runtime/PLAN_DRIVEN_DEVELOPMENT_PROTOCOL.md`; read it before creating or
|
|
advancing an implementation step.
|
|
|
|
- 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.
|