Files
aetherbound-guild/docs/06_DEVELOPMENT_AND_REVIEW.md
T
2026-08-20 18:38:17 +08:00

148 KiB

Aetherbound Guild - Development Plan And Review

Complete-game Goal, hand-drawn repair boundary, ordered implementation plan, roadmap and decision ledger.

Owner Review / Owner 审核

当前唯一执行顺序是:P0 项目总策划与规范整合、启动与首次设置、标题首页、首次四选二建立持久远征团、公会与市场、自动排阵与风险、战斗与结算、第二轮经营、八个区域、结局与通关后玩法。P0 完成前不推进页面代码;之后每一步都从启动页真实可达。

本文件是当前六份审核文档之一。历史拆分文件仅保留在 Git 历史中;文内规则、表格和 ID 仍是完整开发依据。

Repository Reset And Page Production Baseline

Status: OWNER_APPROVED / M01_SYS005_PAGE_DESIGN_IN_PROGRESS Active step: M02_HUB001_OWNER_RUNTIME_ACCEPTANCE

The repository is being reset around one explicit production contract. Product and systems design remain in the six numbered owner documents. Page-specific design authority lives in docs/design-authority/ and is tracked by repository-cleanup-manifest.json and design-index.json.

Page production rule

Every player-facing page must move through the states in docs/design-authority/page-production-contract.json in order:

SPEC_READY
-> AI_DRAFT
-> DRAFT_REVIEW
-> APPROVED_FOR_RECONSTRUCTION
-> DECONSTRUCTION_IN_PROGRESS
-> DECONSTRUCTION_REVIEW
-> ASSET_GENERATION_IN_PROGRESS
-> ASSET_REVIEW
-> RECONSTRUCTION_READY
-> IMPLEMENTATION_IN_PROGRESS
-> IMPLEMENTED_AWAITING_OWNER_RUNTIME_REVIEW
-> VERIFIED_AWAITING_OWNER_ACCEPTANCE
-> COMPLETE

An Owner rejection returns the page to the earliest failed state. Behavior, input or layout tests never close an Owner visual gate. No Godot implementation is legal before RECONSTRUCTION_READY. AI-draft approval authorizes only deconstruction; deconstruction approval authorizes only asset generation; asset approval authorizes the reconstruction package that must be complete before coding.

Each page package must preserve the page contract, state matrix, AI prompt, generation report, approved master, visual deconstruction board, layer map, text slots, responsive anchors, hit-area mapping, asset generation plan, asset contact sheet and provenance, runtime reconstruction package, implementation record, focused verification and Owner acceptance record. The HTML gallery must show AI design, deconstruction, generated assets and runtime evidence as separate inspectable artifacts. A page is not complete because a concept image exists or a headless marker passes.

Cleanup rule

docs/design-authority/repository-cleanup-manifest.json is the sole current branch cleanup register. KEEP paths are current authority or current runtime dependencies. REVIEW paths require a page/replacement decision. A DELETE_CANDIDATE path may be removed only after a fresh reference scan and a focused regression pass. Git history remains the provenance archive; the working tree should contain only current authority, approved page packages, needed runtime dependencies and reproducible tools.

The cleanup baseline and first safe deletion batch are complete at f848e20. SYS-001 Boot and SYS-002 First-launch are complete after Owner runtime acceptance. The approved M01 Entry direction board remains the shared module authority. It defines the shared world/material/control/modal family for SYS-001, SYS-002, SYS-003, SET-001..006 and SYS-008. SYS-002 First-launch v002 is Owner-accepted after focused behavior, parsed input, responsive resize and normal-render evidence. SYS-003 Title v002 is now the sole active runtime review boundary; later pages/modules stay frozen until the Title runtime decision is recorded.

All M01 pages are landscape-first and must declare responsive ownership before implementation. Backgrounds use an explicit aspect-cover or contained-master policy; rails and framed controls use bounded NinePatch/segmented construction; icons and seals retain fixed aspect; localized buttons keep at least 48 logical pixels of touch height and may expand; 760x360, 844x390, 1280x720 and live resize are required before Owner runtime review.

Aetherbound Guild Complete Development Goal

Program ID: ABG-COMPLETE-GAME Status: ACTIVE Owner approval: 2026-08-16 Activation baseline: ee33f775527c20a79703a4fcfe073596c00ca179 Execution topology: one development session; no multi-Agent implementation Master roadmap: 06_DEVELOPMENT_AND_REVIEW.md

Owner Outcome

Continue plan-driven development from the accepted P10.3 Step-2 source until Aetherbound Guild is a complete local release candidate, rather than treating each small runtime slice as an unrelated endpoint. Ordinary implementation may advance without repeated Owner authorization. Every milestone remains bounded, verified, committed, pushed and recorded before the next milestone starts.

Complete Player-Visible Stopping Point

The local candidate must let a new player complete this authored arc:

open the finished landscape game
-> learn Market valuation, Company building and front-to-rear order
-> clear sixteen Contracts across eight mechanically distinct Regions
-> recruit, equip, promote and continuously grow generated Recruits
-> recover knocked-out members at the next stage without losing their identity
-> discover meaningful Profession, Trait, equipment and Artifact combinations
-> defeat sixteen disclosed-rule Bosses
-> choose the finite Chronicle ending or enter Oath Season
-> start a strategically different postgame Contract with the persistent Company

The candidate must contain the complete approved envelope: 12 base, 24 regular advanced and 6 hidden hybrid Professions; 36 Traits; 320 equipment items; 60 Artifacts; 100 ordinary/elite enemies; 16 Bosses; 8 Regions and 16 Contracts.

Experience Contract

  • Fantasy: build a changing guild Company from generated Recruits and keep it alive while restoring a chain of dangerous fantasy routes.
  • Primary action: compare visible capability, cost and threat, then commit a Recruit, item, order, route or run-law choice.
  • Automation: the prepared Party line resolves battle without attack spam; automation exposes causes instead of hiding them.
  • Bottleneck: Coin, one item per Recruit, Line capacity, order, current enemy grammar and current-battle knockouts prevent one solved build.
  • Recurring decision: spend, recruit, reserve, equip, reorder, promote, recover or accept route risk according to the current Company state.
  • Mastery: predict the first decisive interaction and deliberately build a counter without requiring one exact Profession or item.
  • Persistent transformation: Contract clears add Records, Renown, catalog breadth, Region access and optional laws without permanent flat power.
  • Completion: a 15-25 hour first clear and a 60+ hour mastery structure are fully implemented, locally verified and ready for human/device/release gates.

Program Acceptance Gates

Complete Runtime

  • All approved content identities resolve from scalable runtime data and alter a real decision; design-only catalog rows do not count as implemented.
  • The complete Title, Initial Company, Guild Charter, Contract creation, Market, battle, result, recovery, Boss, ending and Oath Season state graph is reachable.
  • One canonical simulation and save authority replaces milestone-only behavior before bulk Region production depends on it.
  • Runtime presentation uses final-direction landscape composition, authored character motion, event-bound damage/healing/status feedback, VFX, music and SFX rather than app-like cards or static debug substitutes.

Verified Candidate

  • Each milestone passes focused negative tests and its actual rendered flow.
  • Campaign-wide normal, active, efficient, adversarial and returning profiles prove pacing, decision density, recovery, anti-dominance and ending reach.
  • Save migration, corruption, rollback, duplicate input, interruption, clock change and zero-offline-value behavior remain authoritative.
  • English, Simplified Chinese, small/reference/large landscape, 130% text, reduced motion/flashes, mute and low power remain usable.
  • The final local candidate has a clean pushed source, source-bound evidence and a fresh H5 review delivery only when the Owner checkpoint authorizes it.

Owner Checkpoints

Ordinary work does not pause between milestones. Owner review is requested at only three planned boundaries:

  1. production-quality visual/audio vertical slice;
  2. the completed RG-04 midpoint build;
  3. the complete first-clear beta/final local candidate.

Owner feedback may reopen the earliest failed player-experience boundary. Automated evidence never closes understanding, fun, visual or listening gates.

Frozen Scope

  • Third-party commercial code, art, music, audio or copied expressive content.
  • Ads, gacha, paid currency, energy, daily-streak or online-required systems.
  • A second battle lane, manual skill spam, same-battle resurrection or fixed authored protagonist relationships.
  • Multi-Agent development unless the Owner explicitly reauthorizes it.
  • Native device packaging, signing, TestFlight, Play Console, store submission, publishing and release acceptance without separate Owner authorization.

Image and TTS generation may use the workspace standing authorization only inside its per-task call and cost ceilings. Video, ElevenLabs music/SFX and any expanded paid batch still require their own authority.

P0 Project Consolidation Plan

Status: COMPLETE Active implementation step: VA-1_GUILD_COMPANY_ANCHOR Code status: FROZEN Stopping point: one Owner-reviewable product, architecture, gameplay, page/interaction, UI, art/audio and development contract with no unresolved authority collision.

P0 is a documentation and dependency-boundary milestone. It adds no page, asset, gameplay rule or package. It consolidates the current authorities and records which historical behavior remains evidence only.

P0 Ordered Work

Step Deliverable Acceptance
P0-1 Product strategy positive fantasy, audience, core loop, session/Contract/campaign shape, completion and canonical vocabulary Owner can explain the game loop and Company/Contract boundary without legacy terms
P0-2 Systems and strategy Recruit, Profession, Trait, Equipment, Party, Risk, Battle, Recovery, levels, economy and failure relationships every recurring decision has a source, cost, consequence and retained state
P0-3 Architecture and Save page/domain/content/save/evidence boundaries, migration and receipt ownership no new UI page owns a domain rule; current path and historical adapters are classified
P0-4 Pages and interaction player-order screen map, page templates, components, modal/notice/error states, input and accessibility each page has first action, Back path, state matrix and 100/130% landscape contract
P0-5 Art/UI/audio contract screenshot-derived visual grammar, character/prop scale, typography, button/modal/HUD rules, motion/audio roles no implementation starts from palette alone; a representative graybox has focal order and asset bindings
P0-6 Cleanup and migration register active, historical, unused-generated and forbidden-to-delete classifications only unreferenced generated/dead files are removed; historical provenance remains traceable
P0-7 Ordered roadmap DEV-1 through DEV-9 substeps, gates, commit boundaries and Owner review points one active step at a time; each step ends with focused evidence and Owner review

P0 Cleanup Rule

Frozen does not mean unused. Current runtime adapters, regression tests, historical assets and rejected candidates remain when they are referenced by the main scene, Save migration, tests or provenance. Temporary Web exports, .godot imports, local Gallery copies and truly unreferenced generated files may be removed after the dependency scan. Every deletion records its path, reason and replacement/retention status in the ledger.

P0 Gate Rules

During P0_PROJECT_CONSOLIDATION and until the next Owner-reviewed page:

  • no DEV-3 visual code continues;
  • no DEV-4+ page or gameplay expansion continues;
  • no bulk asset generation continues;
  • no historical runtime or evidence tree is deleted;
  • no H5 link is presented as a final visual candidate.

P0 Consolidation Record

  • docs/01_GAME_DESIGN.md now provides the positive product contract and authority map. docs/02_GAMEPLAY_AND_BALANCE.md, docs/03_PAGES_AND_UX.md, and docs/04_ART_ANIMATION_AUDIO.md explicitly own systems, player-facing pages and presentation respectively.
  • tools/validate_design_contracts.py now validates the current consolidated six-document layout instead of the retired docs/product split. It passes ABG_DESIGN_CONTRACTS_OK with the declared 8-Region, 42-Profession, 320-equipment and 50-page envelope. tools/validate_predevelopment_design.py passes ABG_PREDEVELOPMENT_DESIGN_OK with zero errors.
  • Dependency review found no safe tracked product file that is both unused and outside runtime, regression or provenance ownership. Temporary Web exports, local Gallery copies and generated caches remain cleanup-only artifacts; the historical runtime/evidence trees remain preserved.
  • P0 is complete. The written Style Bible remains the rule reference, but the next proof is a concrete VA-1_GUILD_COMPANY_ANCHOR page rather than more abstract documentation. DEV-1R_ENTRY_REVIEW, DEV-3V and all later presentation/gameplay expansion remain frozen until the anchor is Owner- reviewed.

DEV-1R Boot Review Candidate

  • Source 23f34bbe669b2d119929d9d4c47e4466cfa2116c changes only the Boot presentation: the existing resource/settings/save checks, named progress, recoverable Retry and first-launch handoff remain unchanged.
  • ABG_DEV1_BOOT_OK and ABG_DEV1_BOOT_RUNTIME_OK pass through separate owned attempts. Twenty entry-matrix captures pass strict diagnostics and layout bounds; focused review uses the Boot frames only.
  • Fresh-start H5 review is published at the share URL recorded in CURRENT_CHECKPOINT.md. DEV-1R remains IN_PROGRESS pending Owner review; first-launch setup, Title and Settings are not yet reopened.

Development Plan V2: Visual Anchor First

Status: OWNER_AUTHORIZED / ONE PAGE AT A TIME Active step: M01_SYS003_RUNTIME_REVIEW Rule: one page, one focused commit, one H5 review; no next page before Owner acceptance.

The existing Company, Contract, Market, Save and battle services remain the functional substrate. The rejected presentation is replaced from one concrete scene outward. No broad feature batch or new asset batch is allowed during the anchor review.

Ordered Steps

Step Player-visible stopping point Narrow acceptance
VA-1A Guild anchor decomposition Layer map, Godot scene tree, asset specifications and reference provenance describe one independent Guild composition COMPLETE; Master B normalized geometry and independent runtime layers are recorded
VA-1 Guild Company anchor One Guild scene shows the persistent Company as complete hand-drawn actors in a bright world with one physical Contract/Market prop, one next action and compact field HUD OWNER_ACCEPTED_FOR_CONTINUATION; Master B remains undistorted inside a centered 16:9 design canvas, non-16:9 space is filled by the World layer, and the repaired Chinese HUD/placeholder frame is the accepted anchor baseline
VA-2 Anchor interaction The same Guild scene supports real tap/mouse/focus on its primary destination, Back, Settings and disabled reason EVIDENCE_COMPLETE / NOT_ACTIVE; parsed Guild interaction and disabled-state evidence pass; Owner explicitly redirected implementation to Title
DEV-1R Entry re-review Boot -> first-launch -> Title -> Settings uses the accepted anchor grammar IN_PROGRESS: TITLE V002 RUNTIME REVIEW; v002 is the sole current Title authority; other pages stay frozen until the Owner records the runtime decision
DEV-2R Initial Company re-review Four candidates, Inspect/Compare, Review and Company handoff use the accepted actor/scene grammar One page at a time; exact four/choose-two behavior remains unchanged
DEV-3R Guild/Contract/Market rebuild Guild -> Contract -> Market -> Recruit/Equipment Review is coherent Each page has its own focused commit and H5; no DEV-4 state is added
DEV-4R Party/Risk presentation Party Line, Readiness and Risk make order, coverage and pressure readable Real touch/focus and state comparison pass before Battle is reopened
DEV-5R Battle loop presentation Battle Opening -> Result -> Knockout -> Recovery uses the same world/actor/HUD grammar Existing battle semantics remain unchanged; Owner reviews one complete first cycle
DEV-6R Company management presentation Equipment, Roster, Recruit Detail, Dismissal and Contract Return use the accepted grammar Persistent growth and receipts remain unchanged; one page per review
CONTENT-1..8 Content production Regions, Contracts and Bosses use the locked presentation contract Produce one playable Region slice, review it, then continue one Region at a time
RC Local candidate Full first-clear path, settings, localization, accessibility and migration are complete Separate human, device, package and release gates remain open until accepted

Current VA-1 repair is limited to responsive Guild composition. Master B geometry, text and hit areas stay together inside the design canvas; resize may add World-layer space outside that canvas but may not change its aspect ratio, crop its Company or controls, or alter Guild/Contract/Market behavior. Final dynamic layer replacement remains a later VA-1 task after this geometry passes focused behavior, narrow-landscape resize, and normal-render review. The current visual repair also replaces AI-master horizontal placeholder marks with engine-rendered Chinese resource/command labels, keeps an English localization branch, and places variable copy inside compact rail slots, the kiosk paper and member name tags.

The repaired M02_HUB001_HUD_TYPOGRAPHY_REPAIR step owned only HUB-001. Source cb6a078 replaced the historical Guild composite with the approved real layered world, Company, Board and segmented rail reconstruction. Its fresh archive passed import, layered structure, 10 parsed touches and 24 normal-render frames with strict diagnostics 0, but Owner runtime review on 2026-08-20 rejected the rendered top and bottom command layers. The repaired stopping point must restore fixed semantic icons to all three top resource cells, keep Settings inside a fixed rail command, replace tiny bottom text tabs with icon-forward destinations, and scale Guild typography with the contained canvas at all four review fixtures. World, actors, Board semantics, Contract/Market behavior and later pages remain frozen. Focused layout/touch verification and four visually inspected frames formed commit 2417b74. A fresh Git archive of that source now passes the layered structure test, 10 parsed Guild touches and four isolated capture fixtures totaling 24 frames with strict diagnostics 0 at /private/tmp/aetherbound-guild-test-evidence/hub001-hud-source-candidate/20260820T084919Z-98413. The active step returns to M02_HUB001_OWNER_RUNTIME_ACCEPTANCE; later pages remain frozen until explicit acceptance. Owner follow-up on 2026-08-20 found one remaining assembly error in that candidate: the bottom center ended at 73% while the fixed Compass texture was centered inside a 27% right region, exposing a large transparent gap and a detached dark base. The active M02_HUB001_BOTTOM_ENDCAP_REPAIR step changes only that center/endcap boundary, adds a structural adjacency assertion, and regenerates the four Guild review frames. Source e2acbd2 implements the 9% fixed Compass region and continuous 91% center boundary. Its fresh archive passes structure, 10 parsed touches and 24 frames with strict diagnostics 0 at /private/tmp/aetherbound-guild-test-evidence/hub001-endcap-source-candidate/20260820T092031Z-20102. The active step returns to M02_HUB001_OWNER_RUNTIME_ACCEPTANCE; all other HUD, typography, world, behavior and later-page scope remains frozen. Owner follow-up on 2026-08-20 rejected the five left bottom commands' percentage-based geometry: their rectangles and spacing grow linearly with the 16:9 canvas, and the round art reads above rather than inside the wood rail. The active M02_HUB001_BOTTOM_NAV_SCALE_REPAIR step replaces only that geometry with 50-76px capped hit targets, independently capped medallion art, compact pixel spacing and a rail-seated vertical position. The 48px minimum, labels, enabled states, Compass endcap, top HUD, behavior and later pages remain frozen. Source 2b732b6 implements the capped geometry and preserves naturally scaled top HUD icons. Its fresh archive passes the layered constraints, 10 parsed touches and 24 frames with strict diagnostics 0 at /private/tmp/aetherbound-guild-test-evidence/hub001-bottom-nav-source-candidate/20260820T093954Z-34122. The active step returns to M02_HUB001_OWNER_RUNTIME_ACCEPTANCE; later pages remain frozen until explicit acceptance. Owner follow-up on 2026-08-20 found a more fundamental mismatch in both rails. The runtime top overlays three opaque rectangular cards and a double-width identity plate over the approved continuous inlaid rail; the runtime bottom shrinks the visible medallions and adds labels, so it no longer matches the approved rail-integrated icon hierarchy. The active M02_HUB001_RAIL_LANGUAGE_REPAIR step changes only those presentation boundaries: use the approved 02C..02G normalized top slots, inlaid parchment value pills without outer cards, distinct status/destination icon geometry, larger bottom medallions inside the capped hit areas, and tooltip/accessibility names instead of visible bottom labels. Touch minimums, semantics, Compass, world, Company, Board, behavior and later pages remain frozen. Source c32967d implements the approved continuous top rail, compact identity pill, icon-plus-value cells, native-width caps and four bottom destinations; Title/Back reuses the left Guild crest instead of adding a fifth medallion. Its fresh archive passes the expanded layered constraints, 10 parsed touches and 24 frames with strict diagnostics 0 at /private/tmp/aetherbound-guild-test-evidence/hub001-rail-language-source-candidate/20260820T103441Z-72079. The active step returns to M02_HUB001_OWNER_RUNTIME_ACCEPTANCE; later pages remain frozen until explicit acceptance.

SYS-003 v002 was implemented and accepted as the previous page. The approved master and separate text-free background extension are imported with linear filtering; normalized engine text and hit areas own New Game, Continue, Settings, Credits and every disabled reason. Focused Title behavior, full entry touch, wider/exact/narrower live resize and the 20-frame entry capture matrix pass with strict diagnostics 0. Its runtime visual acceptance is recorded in the page verification package.

Owner review superseded v001 after identifying a visible two-image join outside the 16:9 canvas and a Title identity placed too close to the crest. The approved v002 authority is one complete 16:9 image under docs/design-authority/pages/SYS-003-title/approved/v002/. Runtime no longer composites a second scene at device edges; it uses a clean sky-toned matte outside the undistorted canvas. Title and command text use the corrected v002 slots. Focused behavior, parsed touch, live resize and the normal-render matrix pass with strict diagnostics 0; v002 remains the only active page and stops for Owner runtime review.

A SYS-002 First-launch Setup v001 image remains DRAFT_REVIEW provenance after three zero-cost provider failures and one completed $0.014 generation. It has no approved/runtime copy and is not imported into Godot; v002 is the sole current First-launch authority.

The completed M01_SYS002_RECONSTRUCTION stopping point was the real First-launch page reached after Boot: six settings controls, a live safe-area/text preview, atomic Apply-to-Title handoff, no Back before completion, and a stable landscape matrix. Focused behavior/input/resize and normal-render evidence remains green in the accepted evidence. The next active stopping point is the SYS-003 Title runtime review; a failed visual review keeps Title active and returns it to the earliest failed state.

Per-Step Execution Loop

freeze scope
-> write one page contract and focal order
-> build one static graybox using existing approved assets
-> Owner visual check
-> implement one real Godot page
-> focused behavior/input test
-> normal-render matrix and fresh-start H5
-> Owner acceptance or repair the same page
-> remove replaced dead UI only after dependency scan
-> focused commit, push, clean worktree
-> activate the next step

Stop Conditions

  • A page that reads as a card wall, generic dashboard, tiny actor list or pixel/retro UI fails and blocks the next page.
  • A green behavior test cannot close a visual gate.
  • A new idea found during a step goes to the issue register; it does not expand the active step.
  • Historical runtime, regression and provenance files are not deleted until a replacement migration and dependency audit prove they are no longer needed.

Current Milestone

P10.3 and FG-2 are functionally complete. FG-3 is locally accepted at pushed source 370f2a5: both RG-02 Contracts, 17 ordinary Rounds, both Bosses, permanent casualty/recovery, two Company Records, first-clear Renown and reload-stable RG-03 unlock pass five-profile simulation, Save-v10 persistence, complete runtime, parsed-touch, audio and MovieWriter gates. FG-4 gameplay, simulation, Save-v11 and Web transport reached a combined midpoint candidate, but Owner review on 2026-08-17 rejected its pixel-art presentation as a contradiction of the accepted Japanese 2D hand-drawn direction. The pixel H5 is not a visual baseline. FG-5 and bulk content remain frozen while the active hand-drawn presentation repair preserves the working systems and replaces only the rejected visual layer. Human comprehension, fun, visual and listening judgments remain open rather than inferred from automation.

Aetherbound Guild complete local candidate ready

or:

Aetherbound Guild complete development redesign required:
<earliest failed product boundary>

FG-4 Japanese 2D Hand-Drawn Presentation Repair Goal

Task ID: ABG-FG4-HANDDRAWN-PRESENTATION-REPAIR Status: OWNER_APPROVED_ENTRY_FIRST Owner direction: 2026-08-17 Planning baseline: d59555c5a3cf95fc44de79ba06c02e650eb3df3b Contract revision: fg4-handdrawn-repair-r1

Earliest Failed Boundary

Gallery item 5vl2EqsYWkey renders the playable midpoint as 16-bit pixel art. The Owner rejected that direction because the accepted product identity is a landscape Japanese 2D hand-drawn fantasy game. Automated layout, asset and runtime checks did not have authority to overrule that human visual decision.

Owner Outcome

Keep the implemented game and restore its approved presentation. Do not restart the battle, progression, content, Save or input systems. Replace the rejected pixel visual layer with thin-line/cel-color actors, softly painted environments and compact field-attached game HUD.

Planning Outcome

The Owner reviewed the redevelopment order and approved player-entry-first implementation. The six numbered documents under docs/ retain:

  1. the canonical product and game-system documents;
  2. the complete 50-page inventory and development order;
  3. the Japanese 2D hand-drawn visual contract;
  4. the runtime art, animation, UI, VFX and audio production plan; and
  5. the full-game roadmap and explicit frozen scope.

The authorization starts only DEV-1: Boot, first-launch setup, Title and essential Settings. Initial Company, Guild, Market, formation, battle, later Regions, bulk generation and delivery remain frozen until their ordered step.

Intended Player-Visible Stopping Point After Approval

open one replacement landscape H5
-> recognize a Japanese hand-drawn fantasy guild battle within three seconds
-> read the imminent enemy action first
-> read the ordered Company line second
-> read the objective and compact controls third
-> watch contact, guard, ranged attack, healing, damage and defeat animation
-> reach result or knockout recovery without leaving the painted world
-> continue into the unchanged RG-03/RG-04 midpoint state

Preservation Boundary

  • Preserve accepted gameplay, economy, content, Save-v11, localization, accessibility, touch, audio-event and simulation behavior.
  • Preserve the rejected pixel assets and H5 as Git history; do not use them as visual authority or expand their asset families.
  • Reuse accepted Phase-6 Japanese hand-drawn concepts and motion sources before requesting new images.
  • Keep engine text and numerical values crisp. Non-text runtime art is smooth hand-drawn/cel-painted work, not nearest-scaled pixels.

Frozen Scope

  • Runtime or gameplay implementation before Owner plan approval.
  • New gameplay, economy, Save version, content rows or balance changes.
  • FG-5 and later Region implementation.
  • New image generation during planning review.
  • Native packages, devices, signing, TestFlight, stores and release.
  • Multi-Agent development.

Planning Terminal

Aetherbound Guild hand-drawn redevelopment plan ready for Owner review

FG-4 Japanese 2D Hand-Drawn Presentation Repair Contract

Revision: fg4-handdrawn-repair-r1 Fixed functional baseline: d59555c5a3cf95fc44de79ba06c02e650eb3df3b Implementation state: DEV_1_ENTRY_FLOW_READY

Visual Identity

An ordinary but capable Japanese fantasy guild forms one continuous horizontal Company line inside a bright, softly painted unstable world. Characters use thin controlled linework, restrained cel color and reference-led proportions. The world, imminent action and line relationship dominate; UI behaves as attached field instruments rather than a separate application dashboard.

Authority

The controlling visual references are:

The generic portfolio pixel-art rule is inapplicable to this repository. The Owner's 2026-08-17 rejection supersedes every machine visual-pass claim made for the pixel H5.

Fixed Battle Comparison

  • Viewport: 844x390, with 760x360 and 1280x720 responsive checks.
  • State: one unchanged midpoint battle fixture with a visible incoming threat, ordered Company, melee contact, ranged action, healing, damage and defeat.
  • First focal read: imminent enemy action and affected target.
  • Second focal read: front-to-rear Company order and active profession action.
  • Third focal read: objective, pause, speed and inspect controls.
  • Ordinary actor scale: no fixed percentage; preserve the complete Company line, enemy relation and movement corridor, then confirm the real runtime frame with the Owner. Bosses may be larger without erasing crowd readability.

Art And Import Rules

  • Background, midground and foreground remain separate editable painted layers.
  • Actor identity is locked before action frames. Body animation and detached VFX remain separate assets with stable pivots, baseline, facing and light.
  • Smooth non-pixel filtering is required for painted sources. Palette reduction, hard square clusters, nearest-neighbor magnification and pixelation are prohibited.
  • Existing accepted sources are audited for reuse before generation. Any future image request uses the installed image-gen route, begins with a dry run and remains within four paid calls and USD 5 for its approved task.
  • Raw generated sheets are never runtime-final. Preserve prompts, task IDs, costs, accepted/rejected cells, processing, hashes and import settings.

UI Rules

  • World and actors occupy the primary surface.
  • Top and bottom HUD rails remain compact and attached to screen edges.
  • One primary action is visually dominant per decision state.
  • Cards are allowed only for repeated offers or inventory entries; nested cards, generic dark panels and explanatory walls are rejected.
  • Engine-rendered Simplified Chinese and English remain readable at 130% text.
  • Touch targets remain at least 48 logical pixels and retain non-color states.

Motion And Feedback

Every representative action has anticipation, committed impact, readable value, recovery and legal terminal state. Required states are idle, advance/contact, melee impact, ranged release, heal, guard, hurt, defeat and victory recovery. Damage/healing values, hit pause, shake and detached VFX follow authoritative events and obey reduced motion/flashes and low-power settings.

Rejection Conditions

  • The result still reads as pixel art, a card application or a text debugger.
  • Actor identity, anatomy, facing, scale, pivot or baseline drifts between frames.
  • The player must read the title or explanatory copy to recognize the fantasy.
  • UI or effects cover the imminent threat, active action, HP or primary control.
  • A concept image is presented as proof of real runtime integration.

Evidence Boundary

Agent inspection may reach agent_visual_reviewed. Only the Owner can restore human_reviewed. Device, packaging, signing, stores and release remain open.

Aetherbound Guild Full-Game Implementation Roadmap

Status: ACTIVE Owner-approved: 2026-08-16 Active phase: FG-4 Japanese 2D Hand-Drawn Entry Flow Program Goal: 06_DEVELOPMENT_AND_REVIEW.md Active milestone plan: 06_DEVELOPMENT_AND_REVIEW.md

Current Truth

  • The complete design catalogs exist, but a design row is not implemented content and a production brief is not a finished asset.
  • RG-01's two Contracts have a verified playable runtime baseline.
  • RG-02 is runtime-verified through Round 4 and stable Market 5.
  • P10.3 is complete through stable Market 8 at simulation_verified + runtime_verified + agent_visual_reviewed. Five profiles and the complete Save-v9/layout candidate matrix pass from fixed source d00c7ad.
  • The executable and production presentation authority now covers 4 of 16 Contracts through the complete RG-02 candidate.
  • FG-2 functional runtime, Web and touch evidence passed at source 3302134, but its pixel presentation is superseded by the 2026-08-17 Owner visual rejection. It is not current art authority.
  • FG-3 source 370f2a5 passes five-profile simulation, 15-state Save-v10 persistence, complete RG-02 normal rendering, parsed touch, media, audio and MovieWriter gates. Read-only PMO acceptance is complete.
  • FG-4 Step 5 source 791187c closes the complete RG-03 candidate. Five profiles cover 265 decisions, 16 winning secondary responses, legacy permanent-loss recovery, nine reloads and 15 Save-v11 states; the retained production runtime passes 12-state layout/accessibility, parsed touch, event-bound audio and a 24.83-second recording. Six of sixteen Contracts now reach simulation_verified + runtime_verified production presentation.
  • The combined RG-03/RG-04 midpoint systems and Web transport pass, but Owner review on 2026-08-17 rejects the pixel-art runtime as a direct contradiction of the accepted Japanese 2D hand-drawn product contract. Systems evidence is retained; the Owner has approved rebuilding presentation in actual player order, beginning with Boot, first-launch setup and Title.

Program Sequence

Only one phase and one child-plan step may be IN_PROGRESS.

Phase Status Player outcome Owned production Exit evidence Owner gate
FG-0 Program activation COMPLETE Development has one visible endpoint and ordered route. Program Goal, roadmap, checkpoint and ledger. Clean pushed planning commit. Approved 2026-08-16.
FG-1 Finish P10.3 COMPLETE Clear Siltwake Rounds 5-7, choose an Artifact, optionally promote and reload at changed Market 8. Existing P10.3 Steps 3-5 only. Battle counterfactuals, five profiles, save/layout matrix, parsed-touch runtime and recording. No pause.
FG-2 Production vertical slice and canonical runtime FUNCTIONAL_COMPLETE_VISUAL_SUPERSEDED One Market -> preparation -> battle -> result/recovery chain executes through the canonical runtime. Runtime/state integration, event-bound feedback and audio routing; pixel art is rejected. Functional regressions, recording, touch and H5 transport remain supporting evidence only. Visual direction reopened 2026-08-17.
FG-3 Complete RG-02 COMPLETE Finish both Siltwake Contracts, both Bosses and unlock RG-03 with a changed persistent Guild. Remaining EQ-065..080, AR-009..015, both RG-02 Bosses, Round 8-12 and complete second Contract content, art and audio. Source 370f2a5; five profiles, 15-state persistence, complete runtime/media/audio candidate. PMO accepted 2026-08-16.
FG-4 Complete RG-03 and RG-04 ENTRY_FLOW_READY Preserve the verified midpoint systems and restore the approved Japanese 2D hand-drawn experience in player order. Boot, first launch, Title, Initial Company, Guild, Market, Party, battle, result/recovery and regional presentation, converting legacy lifecycle semantics only in their named step. End-to-end launch reachability, normal-render motion, responsive states and replacement H5. Checkpoint 2: midgame depth, clarity and continuation.
FG-5 Complete RG-05 and RG-06 PENDING Adapt to echoes, rear intrusion, moving rail order and airborne timing across four Contracts. EQ-161..240, AR-031..045, EN-R5/R6, four Bosses and complete production media. Same content, balance, save, runtime, accessibility and media gates as FG-4. No pause.
FG-6 Complete RG-07 and RG-08 PENDING Resolve hidden-information and synthesis Regions, defeat the final Boss and choose Chronicle or Oath Season. EQ-241..320, AR-046..060, EN-R7/R8, four Bosses, ending, Final Ledger and full campaign presentation. End-to-end first-clear simulations, ending atomicity, full campaign runtime checkpoints and complete content/media coverage. Checkpoint 3: first-clear beta.
FG-7 Mastery and postgame PENDING Discover six hidden hybrids and play strategically different Oath runs without flat-power grinding. Hidden Profession unlocks, optional run laws, alternate Boss breadth, Records, collection knowledge and mastery challenges. 60+ hour modeled breadth, anti-dominance profiles, save migration and representative postgame runtime. No pause unless product depth fails.
FG-8 Alpha, beta and local release candidate PENDING A new player can understand, finish and replay the complete game in a stable local build. Whole-game UX polish, balance, localization, accessibility, performance, lifecycle, final media coverage and defect closure. Full suite, campaign simulations, complete state matrix, normal-render recordings, fresh review H5 and clean pushed source. Final Owner human acceptance remains open.

Milestone Rules

Every phase receives its own child Goal, frozen contract and implementation plan before product edits. Each plan must:

  1. define one player-visible stopping point;
  2. keep exactly one step IN_PROGRESS;
  3. list owned and forbidden paths;
  4. test static/schema, focused behavior, regressions, simulations and runtime in increasing cost order;
  5. create an explicit focused commit and push it before advancing;
  6. update this roadmap, ../CURRENT_CHECKPOINT.md and the append-only ledger only after the actual state changes.

Ordinary completion advances directly to the next approved phase. Work pauses only at the three Owner checkpoints, a real product redesign boundary, an external service/account blocker, or a separately authorized delivery boundary.

Content Completion Definition

A content identity is complete only when its schema validates, mechanic is implemented, references resolve, localization exists, decision counterfactual passes, production asset/audio state is recorded and the content appears in a real rendered encounter. Count-only JSON or Markdown does not close content.

Bulk Region production must reuse the FG-2 canonical runtime and production pipeline. Do not create another phase-specific duplicate simulator for each Region. Compatibility adapters may preserve immutable regressions, but new gameplay authority must have one source of truth.

Planned Human Review Deliveries

  • Checkpoint 1: short H5 focused on final-direction Market, battle motion, result and recovery. This decides presentation before bulk production.
  • Checkpoint 2: continuous build through RG-04 for strategy-depth and comprehension review.
  • Checkpoint 3: complete first-clear beta and later final local candidate.

H5 export/deployment is activated at each checkpoint; native packaging, signing, device installation, stores and publishing remain outside this plan.

Program Issue Register

ID Status Boundary
FG-I01 RESOLVED_FG1 P10.3 Step 3 proves three Artifact and two promotion valuation reversals.
FG-I02 RESOLVED_FG2_STEP1 The campaign adapter now preserves exact P10.0 snapshots/events and forwards all transactions to canonical services.
FG-I03 REOPENED_VISUAL Event-bound motion/audio logic passed local gates, but pixel production art is rejected and must be replaced.
FG-I04 OPEN_OWNER Human comprehension, fun, visual and listening acceptance remain unproven.
FG-I05 FROZEN_DELIVERY Device, packaging, signing, stores and release require separate Owner authorization.
FG-I06 OPEN_VISUAL_REPAIR Owner rejected pixel Gallery item 5vl2EqsYWkey; accepted hand-drawn direction must be restored before FG-5.

Immediate Next Action

DEV-5 is now closed at its source-bound candidate. Before any DEV-6 product code, activate the separate DEV-6 durable plan for second-cycle Company management; no historical casualty or equipment semantics may be inferred.

FG-4 Japanese 2D Hand-Drawn Redevelopment Plan

Status: OWNER_APPROVED Active implementation step: DEV-5D_KNOCKOUT_RECOVERY Goal: 06_DEVELOPMENT_AND_REVIEW.md Contract: 06_DEVELOPMENT_AND_REVIEW.md Page plan: 03_PAGES_AND_UX.md

Development Sequence

Step Status Player-visible outcome Approval boundary
P0 Project consolidation COMPLETE Product strategy, systems, architecture, Save, pages, UI, art/audio and ordered roadmap are one current contract; no new runtime scope ABG_PREDEVELOPMENT_DESIGN_OK; ABG_DESIGN_CONTRACTS_OK; dependency/cleanup classification recorded; Owner-approved next step is DEV-1 re-review
DEV-0 Planning and cleanup COMPLETE Six current documents define the game, pages, art direction and order. Owner approved entry-first development.
UI-0A Complete UI Style Bible COMPLETE Lock visual identity, page templates, components, buttons, text, modals, states, input, responsive, motion, audio relationship and asset standards before further UI code Written sections in docs/03 and docs/04 are complete; the concrete anchor is the next Owner visual gate
VA-1 Guild Company visual anchor OWNER_ACCEPTED_FOR_CONTINUATION One real Guild scene proves actor scale, scene depth, object-led action, HUD rails and the first accepted visual hierarchy Master B composite, responsive geometry and Chinese runtime placeholder repair are accepted as the restoration baseline; later full dynamic layer replacement remains separate
DEV-1 Boot, first launch and Title IN_PROGRESS_SYS003_RUNTIME_REVIEW Re-review the existing Boot, first-launch, Title and Settings path against the consolidated product/UI contract without changing later gameplay scope. SYS-003 v002 is the only active page; focused behavior, responsive captures and Owner review precede Initial Company
DEV-2 Initial Expedition Company COMPLETE Four equal stable generated offers can be inspected; exactly two are selected and committed as the persistent opening roster of one continuous incremental game. Owner accepted candidate v3 for continuation; source-bound DEV-2 and preserved FG-4 suites pass at source 4352e25.
DEV-3 Guild and first Market COMPLETE The Guild identifies the next action; Market comparison and recruit review build the opening Company. Source 0da89b8; all DEV-1/2/3 checks and 24 normal-render states pass after the 760x360 repair.
DEV-4 Automatic formation and risk COMPLETE Player chooses members; the system orders them and exposes protection, reach, threat and reward before commitment. Source 62db001; all DEV-1/2/3/4 checks and 24 normal-render states pass with no battle receipt.
DEV-5 Battle, result and recovery IN_PROGRESS Real melee, ranged, magic, healing, guard, damage, knockout, reward and next-stage recovery complete the first 15-20 minute loop. Owner completes one full first cycle in a playable H5 and sees the same knocked-out Recruit return next stage.
DEV-6 Second cycle and Company management COMPLETE Persistent roster, equipment, levels, dismissal and voluntary Contract return support the bounded second-cycle management path; promotion, Artifacts and later Contracts remain frozen. Source-bound DEV-6 candidate passes all DEV-1..6 markers and 24 normal-render states at source 9617324; human visual/comprehension/fun, device, package, store and release gates remain open.
DEV-7 RG-01 through RG-04 production conversion PENDING Eight Contracts and eight Bosses use the approved hand-drawn presentation over preserved systems. Replacement midpoint H5 passes depth, clarity and continuation review.
DEV-8 RG-05 through RG-08 and ending PENDING Remaining Regions, Contracts, Bosses, catalogs and the First Chronicle ending are complete. End-to-end first-clear beta reaches the finite ending or Oath Season choice.
DEV-9 Postgame and local release candidate PENDING Hidden Professions, Oath laws, Records, all 50 page states, localization, accessibility, performance and defect closure are complete. Final local candidate is ready for separate human/device/package gates.

Why Player Entry Comes First

The Owner must be able to experience every increment in the same order as a new player. A standalone battle frame can validate art but cannot prove launch, navigation, settings, run creation or tutorial continuity. Development therefore keeps one continuous path from Boot to the current stopping point. Battle visual and motion work begins only after New Run, Market, formation and risk can reach it through real navigation.

Execution Boundary

DEV-1 is locally complete and its human gates remain open. The Owner authorized DEV-2 on 2026-08-17 with one corrected product boundary: the choose-two Recruits become a persistent initial Expedition Company, Contract runs are bounded expeditions inside continuous incremental growth, and a zero-HP Recruit returns for the next stage rather than dying permanently.

DEV-2 may correct current design authority, implement the stable initial draft, the choose-two page, its review/commit persistence and a bounded Guild handoff. It may not implement the Guild/Market, retrofit legacy battle/casualty code, change existing FG-4 results, begin DEV-3, generate bulk assets, package or release. The legacy FG-4 implementation remains preserved evidence until its named player-order conversion step.

DEV-1 Durable Implementation Plan

Player-visible stopping point:

launch the real Godot game
-> watch named local verification progress or recover through Retry
-> complete first-launch language, safe-area and accessibility setup once
-> reach the painted Title with truthful New Game, Continue, Settings and Credits states
-> change and persist every essential DEV-1 setting
-> restart or reset the entry state and repeat the complete path

Only one row may be IN_PROGRESS. A failed check keeps that row active.

Substep Status Owned product boundary Narrow acceptance check Commit boundary
DEV-1A SYS-001 Boot COMPLETE New entry controller, resource/settings/save verification, named progress, recoverable error, Retry and safe diagnostics ABG_DEV1_BOOT_OK; ABG_DEV1_BOOT_RUNTIME_OK; strict attempt runner PASS Focused Boot implementation, test, plan/checkpoint update and push
DEV-1B SYS-002 First launch COMPLETE Persistent language, safe area, 100/115/130% text, reduced motion/flashes, captions and usable first-launch completion ABG_DEV1_FIRST_LAUNCH_OK; Boot runtime handoff regression PASS Focused setup implementation, persistence/layout test, plan/checkpoint update and push
DEV-1C SYS-003 Title COMPLETE Painted guild-threshold Title, truthful New Game/Continue/Settings/Credits state and exact return/back behavior ABG_DEV1_TITLE_OK; first-launch regression PASS Focused Title implementation, state/navigation test, plan/checkpoint update and push
DEV-1D SET-001..006 + SYS-008 COMPLETE Settings index, display/text, motion/flash/power, audio/captions, controls, language/locale, credits/licenses/data notice ABG_DEV1_SETTINGS_OK; Title and first-launch regressions PASS Focused Settings/Credits implementation, behavior/localization test, plan/checkpoint update and push
DEV-1E Entry-flow candidate COMPLETE End-to-end player order, responsive refinement, restart/reset fixtures and candidate evidence Source 43e5bac; ABG_DEV1_CANDIDATE_SUITE_OK; ABG_FG4_MIDPOINT_SUITE_OK; strict diagnostics 0 Candidate docs/evidence closure commit and push
DEV-1F Title chrome visual repair COMPLETE Fixed Title frame translates the accepted reference's enamel, ivory, gold-trim, cut-corner, heraldic and icon-forward grammar without copying its battle composition Six DEV-1 headless checks and parsed touch PASS; 20 normal-render development frames cover 760x360/844x390/1280x720, zh_CN/en and 100/130%; focused, primary and disabled states are legible Focused Title chrome implementation, capture, plan/checkpoint update and push
DEV-1G Entry-page visual repair COMPLETE The approved Title grammar extends coherently to Boot, first launch, Settings and Credits without a card wall Six DEV-1 headless checks and parsed touch PASS; final 20-frame normal-render development matrix covers all required sizes/languages/scales with strict diagnostics 0 Focused remaining-page styling, test, plan/checkpoint update and push
DEV-1H Revised entry candidate COMPLETE Complete player-order entry path is source-bound and ready for renewed Owner review Source d3b9326; revised DEV-1 candidate suite and complete FG-4 regression PASS with strict diagnostics 0 Candidate evidence closure commit and push
DEV-1R Entry re-review IN_PROGRESS_SYS003_RUNTIME_REVIEW Re-open the existing DEV-1 path from Boot through first-launch setup, Title, Settings and Credits against the consolidated product/UI contract; no later page or semantic rewrite Focused Title normal-render frames, parsed input and runtime review at the required landscape/text matrix after SYS-002 acceptance Focused Title review evidence, any approved DEV-1 repair commit, plan/checkpoint update and push

DEV-1 owned paths are runtime/entry/, the minimum integration changes to runtime/main.gd, runtime/main.tscn and runtime/project.godot, DEV-1 tests under runtime/tests/dev1/, and existing plan/checkpoint/ledger sections. Existing hand-drawn entry art may be reused with its provenance unchanged. Later gameplay controllers, domain services, content catalogs, Save-v11 rules, battle assets and later-page implementation are preserved and outside this step.

DEV-1 verification increases in cost: static parse/resource checks, the active substep's focused headless behavior test, applicable repository regression, then normal-render runtime and real parsed input. Formal fresh import/capture attempts use tools/run_test_attempt.py with exact required markers. Candidate evidence is bound to a clean committed source; dirty-tree captures are guidance only.

DEV-1 final handoff is exactly ABG DEV-1 candidate ready. It requires focused pushed commits, HEAD == upstream, a clean worktree, no owned test processes, and aligned plan/checkpoint/ledger facts. Human visual/comprehension, device, package, store and release gates remain OPEN.

DEV-1 Issue Register

ID Status Boundary
DEV1-I01 RESOLVED_DEV-1A A bounded entry controller now owns Boot while the historical gameplay facade remains preserved and hidden during normal launch.
DEV1-I02 RESOLVED_REUSE Existing p9_3_guild_hall.png is a usable hand-drawn entry background; no DEV-1 paid image request is currently required.
DEV1-I03 OPEN_HUMAN_REVIEW_REVISED Owner rejected the earlier generic DEV-1 chrome. The revised source-bound runtime repairs that boundary locally; only renewed Owner review can accept it.
DEV1R-I01 OPEN_VISUAL_FAIL The Boot candidate still uses the rejected procedural entry-chrome grammar. A brighter background and translucent lower rail do not satisfy the Owner reference; replace the visual skeleton before first-launch or Title review.
DEV1-I04 RESOLVED_DEV-1F The Title now carries deep-navy enamel, ivory controls, warm-gold layered trim, cut corners, heraldry, compact icon framing and authored focused/primary/disabled states at actual play size. Remaining entry pages are bounded by DEV-1G.
DEV1-I05 RESOLVED_DEV-1G Boot, first launch, Settings and Credits now reuse the Title's enamel, ivory, gold-trimmed, heraldic and icon-forward controls without changing real behavior.

DEV-2 Durable Implementation Plan

Player-visible stopping point:

launch and reach the real Title
-> choose New Game
-> receive four stable generated Recruit offers in fixed positions
-> inspect each Profession, attributes and one Trait benefit/cost
-> compare any two without changing selection
-> select exactly two and review the opening Expedition Company
-> revise or atomically create the persistent opening roster
-> restart at any pre-commit point without rerolling offers or losing selection
-> stop at a truthful Guild handoff; Market and Contract play remain DEV-3+

Only one row may be IN_PROGRESS. A failed check keeps that row active.

Substep Status Owned product boundary Narrow acceptance check Commit boundary
DEV-2A Continuous-growth authority correction COMPLETE Six current documents consistently define one persistent Expedition Company, Contract expeditions that retain roster growth, non-permanent zero-HP recovery at the next stage, and the exact DEV-2 stopping point Cross-document terminology/semantic scan has no authoritative permanent-death or Contract-roster-discard promise; legacy runtime divergence is explicitly frozen; consolidated design and Recruit-loadout validators pass Focused authority/checkpoint/ledger correction and push
DEV-2B Stable initial draft COMPLETE Seed reservation, exactly four valid generated Recruit records, stable IDs/order, selected-ID persistence, retry-safe load and invalid/corrupt recovery ABG_DEV2_DRAFT_OK; create/load/restart, no reroll, zero-to-two selection, duplicate/unknown/three-ID rejection, backup/candidate recovery and no pre-commit roster pass Focused draft service, persistence tests, plan/checkpoint update and push
DEV-2C Recruit choice COMPLETE Title reaches one real Japanese-fantasy selection page with four equal offers, Inspect, Compare A/B, independent Select toggles and exact 0/2..2/2 gating ABG_DEV2_CHOICE_OK; ABG_DEV2_CHOICE_TOUCH_OK; six applicable DEV-1 markers pass; 16 normal-render frames cover choice/selected/inspect/compare at 760x360/844x390/1280x720, zh_CN/en and 100/130% with layout bounds clean Focused selection UI, tests, plan/checkpoint update and push
DEV-2D Review, commit and handoff COMPLETE Review names selected two and unchosen two; Revise preserves the draft; Create atomically writes one persistent roster and reaches a truthful Guild boundary without implementing DEV-3 ABG_DEV2_COMMIT_OK; ABG_DEV2_COMMIT_TOUCH_OK; six applicable DEV-1 and all earlier DEV-2 markers pass; 24 normal-render frames cover choice/selected/inspect/compare/review/guild with strict diagnostics 0 Focused commit/handoff implementation, tests, plan/checkpoint update and push
DEV-2E Initial Company candidate COMPLETE Complete Boot -> setup if needed -> Title -> choose-two -> review -> restart/revise/create -> Guild handoff path is source-bound Source d199053; ABG_DEV2_CANDIDATE_SUITE_OK; ABG_FG4_MIDPOINT_SUITE_OK; strict diagnostics 0; actual-size agent visual review Candidate evidence closure commit and push
DEV-2F Character-forward visual repair COMPLETE One unified compact actor family stands in a shared painted scene; precise ornamental framing, stable content inset and differentiated return/tool/primary commands support rather than re-box the characters Owner accepted v3 for continuation; source 4352e25 passes complete source-bound DEV-2 and preserved FG-4 suites with strict diagnostics 0 Focused visual implementation, asset ledger, tests, plan/checkpoint update and push

DEV-2 owns runtime/entry/, new DEV-2 tests under runtime/tests/dev2/, the minimum main-entry integration and existing authority/checkpoint/ledger sections. It reuses the accepted entry background and procedural chrome; DEV-2F owns only the bounded 12-base-Profession static unit family required by the current pages. Guild/Market, formation, battle, legacy casualty conversion, economy retuning, later Regions and delivery remain outside DEV-2.

DEV-2 final handoff is exactly ABG DEV-2 candidate ready. It requires focused pushed commits, HEAD == upstream, a clean worktree, no owned test processes and aligned plan/checkpoint/ledger facts. Human comprehension/choice/visual, device, package, store and release gates remain OPEN.

DEV-2 Issue Register

ID Status Boundary
DEV2-I01 RESOLVED_DEV-2A All six current authorities now place the persistent Company/knockout rule first; contradictory FG-4 lifecycle details are explicitly frozen legacy evidence and current New Game/Company pages use the corrected model.
DEV2-I02 FROZEN_LATER_CONVERSION Existing FG-4 gameplay and Save-v11 implement the superseded casualty/run model; DEV-2 preserves them and does not claim they already satisfy the new authority.
DEV2-I03 RESOLVED_REUSE Accepted painted entry art plus procedural enamel/ivory/gold chrome cover the initial-company page; no paid generation is required.
DEV2-I04 RESOLVED_DEV-2B A dedicated Initial Company draft service now persists one seed, four fixed complete offers and zero-to-two selected IDs without creating current_run, a Contract or a Company before commit.
DEV2-I05 RESOLVED_DEV-2C Title now reaches the real four-offer page; Inspect/Compare do not mutate selection, a third selection is visibly rejected, only exactly 2/2 enables Review, and Back/restart preserve the draft.
DEV2-I06 RESOLVED_DEV-2D Review distinguishes the selected persistent pair from two discarded provisional offers; Company creation is atomic and idempotent, stores no Contract reset or unchosen Recruit, and restart reaches a truthful bounded Guild handoff.
DEV2-I07 RESOLVED_OWNER_CONTINUATION Owner accepted frame/spacing candidate v3 and explicitly authorized progression into DEV-3 through DEV-6. Broader comprehension/fun, device and release gates remain separately open.
DEV2-I08 RESOLVED_CHARACTER_FORWARD The final choice, Inspect, Compare, Review and Guild pages use person-bearing controls and one shared painted scene rather than the rejected card/text wall.
DEV2-I09 RESOLVED_UNIFIED_ACTORS The mixed-source set and first tall unified sheet are superseded. All 12 base Professions use one compact 4.5-5-head line/face/cel/light family at accepted choice, Inspect and Guild scales.
DEV2-I10 RESOLVED_BUTTON_HIERARCHY Candidate v2 replaces repeated double-gold boxes and generic diamonds with parchment return tabs, compact A/B markers, plus/check selection, compare arrows and confirmation checks. Owner follow-up does not reopen that button hierarchy; the remaining rejection is frame craftsmanship and spacing in DEV2-I12.
DEV2-I11 ACTIVE_EXECUTION_CONSTRAINT Owner rejects opaque, repeated long regression cycles during visual iteration. DEV-2F uses only the focused current-page interaction check and six representative frames; any check expected to exceed 60 seconds must be named with purpose and duration before it starts, and full DEV-2/FG-4 regression waits for visual-direction acceptance.
DEV2-I12 RESOLVED_OWNER_ACCEPTED_V3 Candidate v3 separates frame and content safe rectangles: one complete cut-corner hairline, four constructed corner fittings and aligned header/footer rails sit outside a stable inner inset. Owner accepted the result for continuation.

DEV-2F Owner Rejection Recurrence Check

Every DEV-2F runtime frame must be checked against all prior Owner feedback before it is sent for review. A later repair does not erase an earlier rule.

  • Recruits remain the first visual read; repeated text plates or a card wall may not reclaim the composition.
  • All 12 base-Profession actors use one approved drawing family: matching face/eye construction, compact proportion, line hierarchy, cel-shadow count, material density, light and play-size treatment. Mixed legacy actor batches are prohibited.
  • Choice and Guild actor scale must retain visible environment and complete silhouettes; Inspect/Compare may enlarge actors without changing their style.
  • Return, A/B tools, comparison, selection and confirmation must have distinct silhouettes and familiar semantic symbols. A generic diamond repeated on every command is prohibited.
  • Initial Company pages use open corner ornaments and header/footer rails; repeated heavy octagonal button frames are prohibited. One precise complete outer hairline is allowed when it is paired with authored corner fittings and a separately inset content rectangle; sparse unfinished corner strokes and content touching ornament are prohibited.
  • Visual iterations use focused behavior plus representative normal-render frames. Full source-bound regression runs once after the Owner-facing visual direction stops changing, not after every chrome adjustment.
  • Before any check expected to exceed 60 seconds, state its exact scope, necessity and expected duration to the Owner. Do not hide a complete legacy suite behind the generic word Runner; the runner is only the required isolation, process-group cleanup, strict-marker and evidence-retention shell.
  • Each Owner rejection or approval updates the active issue row, checkpoint and ledger before the next candidate. human_reviewed remains false until the Owner explicitly accepts the current runtime revision.

DEV-3 Durable Implementation Plan

Player-visible stopping point:

launch and Continue the persistent two-Recruit Expedition Company
-> see the Guild name the first Contract as the next action
-> inspect an unlocked Contract and choose difficulty without changing state
-> confirm one bounded Contract with 52 Coin and Line capacity four
-> enter one stable Market with three Recruit, four equipment and three battle offers
-> inspect an offer without buying from the list
-> review exact Recruit identity, Profession, Trait benefit/cost, attributes,
   starting item, price and Company/Line effect
-> Cancel to the same offer or confirm one atomic hire
-> complete a second independent review and hire
-> stop in the same Market at Company four, Line capacity four and 24 Coin

Only one row may be IN_PROGRESS. A failed check keeps that row active.

Substep Status Owned product boundary Narrow acceptance check Commit boundary
DEV-3A Contract foundation COMPLETE One authoritative migration of the verified Company store adds zero-or-one active Contract, deterministic first-Market state, 52 Coin, Line capacity four, operation receipts and retry-safe persistence without changing the two existing Recruit records ABG_DEV3_CONTRACT_OK; v1 migration, create/retry/conflict, candidate/backup recovery, exact 3/4/3 board and restart stability pass Focused Contract/Market domain service, persistence test, plan/checkpoint update and push
DEV-3B Guild and Contract choice COMPLETE The real Guild identifies the next action, opens one unlocked Contract review, changes difficulty without commitment and creates the bounded Contract only after explicit confirmation ABG_DEV3_GUILD_OK; Continue/Guild/review/cancel/confirm/restart and visible disabled-reason paths pass with no Market purchase or DEV-4 state Focused Guild/Contract UI, input test, plan/checkpoint update and push
DEV-3C Stable Market and Recruit review COMPLETE A physical requisition surface exposes all 3 Recruit, 4 equipment and 3 battle offers; list actions only inspect, while Recruit review shows exact decision data and Cancel returns to the invoking stable offer ABG_DEV3_MARKET_OK; board identity, list/review separation, exact price/affordability/capacity copy, cancel/focus restoration, localization and restart pass Focused Market/review UI, behavior test, plan/checkpoint update and push
DEV-3D Atomic first hires COMPLETE Two separately reviewed affordable level-1 Recruit offers each create one idempotent receipt and update Coin, ownership and offer state atomically from Company 2 to 3 to 4 while Line capacity remains four ABG_DEV3_HIRE_OK; exact combined 28 Coin cost and 24 Coin remainder, double-confirm, new-ID retry, stale/unaffordable/capacity-display and interrupted-write recovery pass Focused hire transaction/UI feedback, persistence/input test, plan/checkpoint update and push
DEV-3E Guild/Market candidate COMPLETE The source-bound Title/Continue -> Guild -> Contract/difficulty -> Market -> two separate Recruit reviews/hires path is responsive, persistent and stops before formation/risk Source 0da89b8; six DEV-1, six DEV-2, four DEV-3 markers and 24 normal-render frames PASS with strict diagnostics 0 Candidate evidence closure commit and push

DEV-3 owns the minimum Company-store migration, Contract/Market domain service, Guild/Contract/Market/Recruit-review runtime in runtime/entry/, focused tests under runtime/tests/dev3/, and existing checkpoint/contract/ledger sections. It reuses the accepted painted Guild scene, unified compact Recruit family and precise inset/frame/button grammar. Equipment and battle offers are inspectable but cannot be purchased or committed in DEV-3. Automatic formation, Party-line editing, risk selection, battle, result, knockout recovery, second-cycle management, later Regions, bulk assets, devices, packages and release remain outside DEV-3.

DEV-3 verification increases in cost from static/domain persistence, to the active focused behavior/input test, then the source-bound DEV-3 path and a small representative normal-render matrix. The preserved full FG-4 suite is not repeated during ordinary DEV-3 substeps; it runs once at the final applicable regression boundary. Any check expected to exceed 60 seconds is named with scope, purpose and expected duration before it starts.

DEV-3 final handoff is exactly ABG DEV-3 candidate ready. It requires focused pushed commits, HEAD == upstream, a clean worktree, no owned test processes and aligned plan/checkpoint/ledger facts. Human visual/comprehension/fun, device, package, store and release gates remain OPEN.

DEV-3 Issue Register

ID Status Boundary
DEV3-I01 RESOLVED_DEV-3A Company schema v2 migrates valid DEV-2 v1 data in place and stores the sole active Contract, deterministic Market and receipts in the same redundant atomic file.
DEV3-I02 FROZEN_LEGACY Historical FG-4 Contract services retain superseded roster-loss semantics and cannot be adopted as current authority without conversion in their named later step.
DEV3-I03 ACTIVE_RECURRENCE_CHECK Guild and Market must preserve character-first staging, stable content/frame insets and differentiated commands. A card/text wall, recommended Recruit, combined Hire two, list-row purchase or silent disabled control is prohibited.
DEV3-I04 OPEN_HUMAN_GATE Automated/runtime evidence cannot grant understanding of Company versus Line capacity, purchase choice quality, visual acceptance or willingness to continue.
DEV3-I05 RESOLVED_CANDIDATE Source a0918bc passed all 16 behavior/touch checks but failed its first normal-render fixture because the 760x360 Market footer extended 2 px below the viewport. Source 0da89b8 contains the short-screen repair and passes the entire fresh source-bound matrix.

DEV-4 Durable Implementation Plan

Player-visible stopping point:

launch and Continue at the stable first Market with four owned Recruits
-> enter Party Line only after both opening hire receipts exist
-> see all four members placed on one rear-left to front-right cord
-> identify exposed position 0, protection, reach and the first known threat
-> select a member and swap destinations without drag
-> compare the exact relation changes, Undo or Reset, then save one atomic order
-> review and accept the frozen readiness snapshot without starting battle
-> compare three stable risk options with no recommendation or automatic choice
-> inspect known threat, uncertainty, entry cost, reward and recovery exposure
-> Cancel safely or open the selected risk commitment with the same party snapshot
-> stop before Begin Battle; DEV-5 owns the first battle receipt and simulation

Only one row may be IN_PROGRESS. A failed check keeps that row active.

Substep Status Owned product boundary Narrow acceptance check Commit boundary
DEV-4A Formation/risk foundation COMPLETE In-place Company/Contract migration adds one deterministic prepared-party draft, rear-left/front-right order rules, three stable first-battle risk projections and retry-safe formation/readiness receipts without creating a battle receipt ABG_DEV4_FOUNDATION_OK; v2 migration, exact four unique owned IDs, deterministic auto-order, swap/reset, stale/capacity rejection, atomic save/retry/recovery and three stable risk projections pass Focused Company/Contract service, domain test, plan/checkpoint update and push
DEV-4B Party Line COMPLETE Market reaches a character-forward horizontal Party Line where all four unified actors occupy numbered positions; tap-select/tap-destination previews protection, reach, target and threat changes with usable Undo/Reset/Back ABG_DEV4_PARTY_OK; player-order navigation, no-drag input, exact position orientation, relation deltas, cancel/restart restoration, localization and 130% text pass Focused Party Line runtime/input test, plan/checkpoint update and push
DEV-4C Readiness snapshot COMPLETE Save Order atomically persists the order and a separate readiness page freezes member IDs, positions, relation summary and allowed warnings; Accept records one idempotent prepared snapshot but starts no battle ABG_DEV4_READY_OK; save/retry/conflict, warning ownership, revise/restart and zero battle/risk-commit receipt pass Focused readiness service/UI/test, plan/checkpoint update and push
DEV-4D Risk selection and commitment preview COMPLETE A region-attached risk board compares three stable options in the required known-threat/uncertainty/cost/reward/recovery/coverage order; selection mutates nothing and commitment review retains the frozen party ABG_DEV4_RISK_OK; no auto-selection/recommendation, select/cancel/restart, stale dependency rejection and truthful DEV-5 Begin Battle boundary pass Focused risk board/commitment UI/input test, plan/checkpoint update and push
DEV-4E Formation/risk candidate COMPLETE The source-bound Title/Continue -> Market -> Party Line -> readiness -> risk review path is responsive, persistent, layout-safe and stops before battle commit Source 62db001; six DEV-1, six DEV-2, four DEV-3, four DEV-4 markers and 24 normal-render frames PASS with strict diagnostics 0 Candidate evidence closure commit and push

DEV-4 owns only the smallest in-place Company/Contract migration, prepared-party and risk projections, Party Line/readiness/risk runtime under runtime/entry/, focused tests under runtime/tests/dev4/, and existing checkpoint/plan/ledger sections. It reuses the accepted painted Guild scene, unified compact Recruit family and precise inset/frame/button grammar. The open world must remain the dominant surface; Party and risk information attach to actors, the horizontal cord or one comparison band rather than becoming a card wall.

Battle receipt creation, battle simulation, result, reward, knockout recovery, second-cycle management, equipment purchase/equip, Artifacts, promotion, dismissal, later Regions, bulk assets, H5/native packages, devices, stores and release remain outside DEV-4. DEV-4 may show the real Begin Battle command only as unavailable with the explicit DEV-5 boundary; it cannot silently respond or pretend a battle was committed.

DEV-4 verification increases from static/domain persistence, to the active focused behavior/input check, then one source-bound path and a representative normal-render matrix. Ordinary substeps do not repeat the complete legacy suite. Any check expected to exceed 60 seconds is named with scope, purpose and expected duration before it starts. Every attempt uses the checked-in runner, retains compact evidence under ABG_EVIDENCE_DIR, and cleans its complete owned process group.

DEV-4 final handoff is exactly ABG DEV-4 candidate ready. It requires focused pushed commits, HEAD == upstream, a clean worktree, no owned test processes and aligned plan/checkpoint/ledger facts. Human visual/comprehension/fun, device, package, store and release gates remain OPEN.

DEV-4 Issue Register

ID Status Boundary
DEV4-I01 RESOLVED_DEV-4A FormationRiskService initializes one optional strict formation block in the schema-v2 Contract. It preserves four Recruit hashes, 24 Coin, the 3/4/3 board and both DEV-3 hire receipts outside newly owned fields.
DEV4-I02 FROZEN_LEGACY Historical automatic-formation/risk/battle controllers contain superseded run/casualty semantics and cannot become current persistence authority; compatible ordering and visual vocabulary may be independently projected through the current Company store.
DEV4-I03 ACTIVE_RECURRENCE_CHECK Party Line and risk must remain actor/scene-first, use stable content insets, keep controls away from frame edges and use differentiated semantic commands. Repeated text cards, decorative diamonds and silent unavailable actions are prohibited.
DEV4-I04 OPEN_HUMAN_GATE Automated/runtime evidence cannot prove that a player understands rear versus front, position 0, protection, reach, threat, uncertainty or the risk tradeoff.
DEV4-I05 FROZEN_DEV-5 DEV-4 ends before the first battle transaction. The commitment preview must name that boundary until DEV-5 is separately activated after a pushed DEV-4 candidate.

DEV-5 Durable Implementation Plan

Player-visible stopping point:

Continue from accepted Risk Commitment
-> create one battle receipt from the frozen Party and selected risk
-> read the objective, actor order, enemy-facing direction and first telegraph
-> watch deterministic melee, ranged, magic, healing, guard and damage events
-> pause or resume observation without issuing a combat command
-> reach a truthful Victory/Defeat result with the first decisive cause
-> inspect Coin/XP/reward and the same Recruit's knockout identity if present
-> acknowledge the battle-local knockout and open next-stage recovery
-> see the same Recruit return with stable ID, Profession, Trait and equipment
-> stop at next-stage readiness; equipment/build management remains DEV-6

Only one row may be IN_PROGRESS. A failed check keeps that row active.

Substep Status Owned product boundary Narrow acceptance check Commit boundary
DEV-5A Battle foundation COMPLETE In-place Contract extension creates one retry-safe battle receipt from accepted formation/risk, deterministic event timeline and strict terminal/result/recovery predicates without using historical casualty code ABG_DEV5_BATTLE_OK; begin validation, duplicate/conflict, snapshot/risk identity, exact event kinds/order, deterministic outcome, interruption and no duplicate reward pass Focused battle service/domain test, plan/checkpoint update and push
DEV-5B Battle opening/live observation COMPLETE Real Godot Battle Opening and Live Battle scene uses the painted environment, four compact actors, enemy-facing gap, disclosed threat, automatic playback, pause/resume and causal event rail ABG_DEV5_BATTLE_UI_OK; Title/Continue -> battle, actual actor order, event timing, pause/resume, 130% layouts, touch/controller path and no combat command prompt pass Focused battle runtime/input/capture test, plan/checkpoint update and push
DEV-5C Result and diagnosis COMPLETE Victory/Defeat result names objective, first decisive event, reward, XP and downstream state; one reviewable causal chain precedes Continue ABG_DEV5_RESULT_OK; result receipt, duplicate settlement, reward/XP totals, cause inspect, restart and truthful loss state pass Focused result/diagnosis UI/domain test, plan/checkpoint update and push
DEV-5D Knockout and next-stage recovery COMPLETE Knockout review names stable Recruit identity, current-battle absence and next-stage return; recovery atomically restores battle readiness without permanent death or roster replacement ABG_DEV5_RECOVERY_OK; same ID/Profession/Trait/equipment, recovery receipt, duplicate/retry/candidate recovery, no permanent removal and next-stage handoff pass Focused recovery UI/persistence/input test, plan/checkpoint update and push
DEV-5E First-cycle candidate COMPLETE Source-bound Title/Continue -> Market -> Party -> Readiness -> Risk -> Battle -> Result -> Recovery path completes one first cycle at required landscape sizes and stops before DEV-6 management All applicable DEV-1/2/3/4/5 markers, parsed touch and representative 760x360/844x390/1280x720 zh_CN/en 100/130% normal-render states pass with strict diagnostics 0 Candidate evidence closure commit and push

DEV-5 owns only the minimum battle state, event timeline, result/diagnosis and battle-local knockout/next-stage recovery around the accepted DEV-4 snapshot. It may reuse existing enemy/content catalog rows and unified Recruit textures, but it must not adopt historical permanent-death, Replacement Credit, Company-collapse or roster-archive semantics. The first battle is automatic; pause, speed and inspect are observation controls, not combat actions.

Equipment purchases/equip, Artifacts, promotion, dismissal, second-cycle management, Contract return semantics beyond the recovery handoff, later Regions, bulk assets, devices, packages, stores and release remain outside DEV-5. DEV-6 requires a separately activated plan after ABG DEV-5 candidate ready.

DEV-5 verification increases from battle-domain persistence to focused runtime and parsed input, then source-bound first-cycle rendering. The preserved legacy FG-4 suite remains historical and is not a substitute for the new current Company/battle boundary. Any check expected to exceed 60 seconds is named with scope, purpose and expected duration before launch; every attempt owns and cleans its complete process group under ABG_EVIDENCE_DIR.

DEV-5 final handoff is exactly ABG DEV-5 candidate ready. Human visual/comprehension/fun, device, package, store and release gates remain OPEN.

DEV-5 Issue Register

ID Status Boundary
DEV5-I01 RESOLVED_DEV-5A BattleService independently attaches one current receipt/timeline to the schema-v2 Company/Contract and never calls historical casualty/run services.
DEV5-I02 FROZEN_LEGACY Existing permanent-death, Replacement Credit, Company-collapse and roster-archive behavior cannot be surfaced as current product truth.
DEV5-I03 RESOLVED_DEV-5B_LOCAL Battle keeps actors and event projections dominant, preserves the accepted Japanese 2D scale, and avoids a dashboard/card wall or combat command prompt in the focused runtime check.
DEV5-I04 OPEN_HUMAN_GATE Automated evidence cannot prove that the player understands the first decisive cause, battle-local knockout, reward or next-stage return.
DEV5-I05 FROZEN_DEV-6 Equipment/build management and second-cycle Company decisions begin only after DEV-5 recovery candidate closure.
DEV5-I06 RESOLVED_DEV-5C Settlement keeps exactly nine timeline events, points diagnosis at decisive damage, awards XP only to surviving members and keeps the 130%-text Continue action inside the 844x390 viewport.
DEV5-I07 RESOLVED_DEV-5D Knockout Review and Recovery commit preserve the same Recruit identity, Profession, Trait, level/XP, history and equipment, then return to Market with one retry-safe receipt and no permanent death.
DEV5-I08 RESOLVED_DEV-5E The historical DEV-4 risk marker required a disabled Begin Battle boundary; the DEV-5 candidate omits that superseded assertion and verifies its replacement through the real Risk -> Battle marker.

DEV-6 Durable Implementation Plan

Status: SUSPENDED_BY_P0_PROJECT_CONSOLIDATION Active implementation step: P0_PROJECT_CONSOLIDATION

Player-visible stopping point:

restart at next-stage Market after DEV-5 recovery
-> inspect four persistent equipment offers and their sourced effects/costs
-> review one equipment offer against an eligible Recruit
-> commit one-slot equipment purchase/equip with a retry-safe receipt
-> inspect the same Company's roster, level/XP, Trait, Profession and history
-> restart and return to the same Market/Roster state without duplicating Coin or equipment
-> stop before dismissal, promotion, Artifacts, second Contract creation and a second battle

Only one row may be IN_PROGRESS. Every substep ends with a focused pushed commit and checkpoint update before the next row becomes active.

Substep Status Owned product boundary Narrow acceptance check Commit boundary
DEV-6A Company growth foundation COMPLETE Persistent equipment inventory, one universal equipped slot, sourced purchase/equip receipt, individual level/XP readout and duplicate/conflict/insufficient-Coin behavior ABG_DEV6_GROWTH_OK; equipment offer identity/effect/price, valid and invalid wearer, one-slot replacement, Coin delta, receipt retry/conflict, XP/level persistence and restart pass Focused domain/runtime test, plan/checkpoint update and push
DEV-6B Roster and Recruit detail COMPLETE Guild Roster and Recruit Detail expose stable identity, Profession, Trait, level/XP, equipment, history, readiness and legal navigation ABG_DEV6_ROSTER_OK; list/detail/back/restart and truthful empty/disabled actions pass Focused roster UI/input test, plan/checkpoint update and push
DEV-6C Dismissal and Contract return COMPLETE Dismissal review verifies live-count eligibility; Contract return preserves Company growth and separates voluntary withdrawal from Recruit dismissal ABG_DEV6_RETURN_OK; final-member disabled reason, explicit confirmation, equipment return, Coin preservation, receipt retry/conflict and Guild return pass at /private/tmp/aetherbound-guild-test-evidence/dev6-return/20260818T042042Z-47775; DEV-6A/6B/5 regressions pass Focused dismissal/return domain and UI test, plan/checkpoint update and push
DEV-6D Second-cycle candidate COMPLETE Source-bound next-stage Market -> equipment -> roster/detail -> Guild/Contract Return path completes and stops before new battle/content Source 96173243765bc7fe897c13bafebf0affa8a033e6; ABG_DEV6_CANDIDATE_SUITE_OK, all prior markers, parsed touch, 24 normal-render states and strict diagnostics 0 at /private/tmp/aetherbound-guild-test-evidence/dev6-candidate-final/20260818T043605Z-66692 Candidate evidence closure commit and push
DEV-6V Content-surface visual repair FROZEN_BY_P0 First publish the Owner-provided DEV-3 UI Style Contract, then repair DEV-3 onward Guild, Market, Recruit/Equipment review, Roster/Detail and Return surfaces so characters and scene/HUD hierarchy lead; preserve accepted DEV-1/DEV-2 Boot, Title and choice baseline and all Company/Save/Battle semantics P0 must unify the product/UI contract before DEV-6V resumes Focused presentation commit, H5 export/publish evidence and checkpoint update

DEV-6 may reuse existing equipment catalog rows and hand-drawn Recruit assets, but it must not surface historical P9/FG-4 run-state or permanent-death semantics as current truth. Promotion, Artifacts, dismissal, second Contract creation, later Regions, bulk assets, devices, packaging, stores and release remain frozen until their named DEV-6 substep.

Aetherbound Guild Development Ledger

This append-only ledger records current milestone decisions. Superseded test attempt details remain available in Git history and external evidence roots; they are not duplicated here.

2026-08-16 - Complete Game Program Approved

  • The Owner approved plan-driven development toward eight Regions, sixteen Contracts, the First Chronicle ending and Oath Season postgame.
  • Single-session implementation is required. Native delivery remains separate.

2026-08-17 - Functional Midpoint Reached

  • RG-03 and RG-04 gameplay, four Contracts, four Bosses, Save-v11 and five profiles reached a combined automated/simulation/runtime midpoint candidate.
  • Runtime-only Web and Gallery transport passed.
  • These checks did not grant human visual, comprehension, fun or listening acceptance.

2026-08-17 - Pixel Presentation Rejected

  • Owner reviewed Gallery item 5vl2EqsYWkey and rejected its 16-bit pixel-art presentation.
  • Accepted authority remains Japanese 2D thin-line/cel-color characters over softly painted environments. Unit scale follows the accepted reference and Owner review of a real runtime frame, not a fixed percentage.
  • Root cause: FG-2 incorrectly treated a generic portfolio pixel-art rule as stronger than this game's approved product and visual contracts.
  • Gameplay, content, Save, input and event-bound audio remain preserved.
  • FG-5, bulk asset production and delivery are frozen.

2026-08-17 - Planning And Documentation Reset

  • The repository-specific Agent contract now excludes Aetherbound from the portfolio pixel-art rule.
  • Current product documentation is exactly the six numbered Markdown files under docs/; README.md is the clickable review index.
  • Historical milestone Goals, plans, H5 notes, attempt reports and rejected generation Markdown are removed from the current tree; Git history retains them.
  • All 50 canonical pages and the implementation order are defined in 03_PAGES_AND_UX.md.
  • The planning freeze ended when the Owner approved entry-first development. The first product action is the real Boot, first-launch and Title path.
  • Consolidation validation proves both page authorities contain the same 50 IDs and retains 42 Professions, 36 Traits, 320 equipment items, 60 Artifacts, 100 enemies, 16 Bosses and 8 Regions.

2026-08-17 - Entry-First Development Order Approved

  • The Owner rejected a battle-first implementation order and required the game to be developed in the same sequence a new player experiences it.
  • DEV-1 begins with Boot, first-launch setup, Title and essential Settings.
  • Initial Company, Guild, Market, automatic formation, risk, battle, result and later content remain ordered follow-up steps rather than parallel work.
  • One HAPI development session works directly in the current repository and branch; no multi-Agent or new worktree is authorized.

2026-08-17 - DEV-1A Boot Implemented

  • Normal launch now enters a bounded Godot entry shell over the existing hand-drawn guild threshold; the historical gameplay facade remains preserved.
  • Boot verifies required local resources, user storage, settings data and the current save envelope with named progress. Unsafe data is not reset.
  • Recoverable failure retains the branded screen, a stable non-path diagnostic and Retry. Focused service and real-main-scene tests pass with strict markers ABG_DEV1_BOOT_OK and ABG_DEV1_BOOT_RUNTIME_OK.

2026-08-17 - DEV-1B First Launch Implemented

  • A clean profile must apply language, safe-area, 100/115/130% text, reduced motion/flashes and caption settings before reaching Title.
  • Settings use schema validation and verified candidate/backup promotion. A completed setup survives restart and is not forced again; the dedicated reset fixture restores first-launch behavior without changing run data.
  • The focused persistence and screen-state marker ABG_DEV1_FIRST_LAUNCH_OK and the Boot handoff regression pass.

2026-08-17 - DEV-1C Title Implemented

  • The Title uses the approved hand-drawn guild threshold and keeps New Game, Continue, Settings and Credits in a compact operational hierarchy.
  • Continue reflects the verified local-save envelope and shows a visible reason when disabled. New Game and Continue preserve frozen DEV-2/save semantics and state the unavailable downstream review instead of silently doing nothing.
  • Settings/Credits return exactly to Title, while Back opens a non-destructive exit review. ABG_DEV1_TITLE_OK passes with no-save and resumable fixtures.

2026-08-17 - DEV-1D Settings And Credits Implemented

  • SET-001..006 provide stable category navigation and persisted display/text, motion/flash/power, audio/caption, control and locale behavior with explicit Apply/Discard handling and exact Title return.
  • Master mute plus Music/SFX levels apply to real Godot buses. Absent separate Ambience/Voice assets and conflict-safe remapping remain visible with precise unavailable reasons rather than inert controls.
  • SYS-008 names authorship, bundled SIL font license, offline behavior, local data/privacy and the no-external-link policy. ABG_DEV1_SETTINGS_OK and the preceding Title/first-launch regressions pass.

2026-08-17 - DEV-1 Candidate Verified

  • Candidate product source: 43e5bacbf88953ae99676400532189f02143be20.
  • Source-bound DEV-1 attempt: /private/tmp/aetherbound-guild-test-evidence/dev1-candidate/20260817T072754Z-25813; PASS with archive SHA-256 46fedaed64f73519ad0e55aa5094cecbebe95e8c94a1e2fb6ab58a3b5356e947. It covers fresh import, Boot/setup/Title/Settings/Credits behavior, real parsed ScreenTouch, restart/reset, 20 normal-render frames, 760x360/844x390/ 1280x720, English/Chinese and 100/130% text with strict diagnostics 0.
  • Source-bound preserved-system regression: /private/tmp/aetherbound-guild-test-evidence/dev1-fg4-regression-3/20260817T081131Z-73011; PASS with archive SHA-256 6b1dd652e8351d1f4f993dc26cd4a6650513e1905bf626d4a9ff20411864738f. All 30 Godot checks, five Python/media checks, 24 legacy normal-render frames, Save-v11, five-profile midpoint simulation and existing parsed-touch paths remain unchanged and strict.
  • Local runtime inspection at the time reached agent_visual_reviewed: the painted guild threshold was visible, focal order was clear and tested short/130% states did not overlap. This agent-only visual state was later superseded by the Owner's rejection below.
  • DEV-1 used existing approved-direction art and made zero paid image calls. Device, packaging, signing, store and release gates remain open and were not exercised.

2026-08-17 - DEV-1 Entry Chrome Rejected

  • The Owner compared the functional DEV-1 runtime with 05_battle_ui_japanese_scale.png and reported a substantial mismatch.
  • Earliest failed boundary: the runtime used generic translucent rectangles and flat settings controls instead of the reference's deep-navy enamel, ivory control plates, warm-gold layered trim, cut corners, heraldic anchors, icon-forward hierarchy and authored interaction states.
  • The functional DEV-1 and preserved FG-4 evidence remains valid only for its named behavior. DEV-1F reopens visual production at the Title fixed frame; Boot, first launch, Settings and Credits follow only after that grammar works at actual play size. No paid generation is yet justified because approved background art and procedural Godot chrome cover this bounded repair.
  • Human visual/comprehension, device, packaging, store and release gates remain open. DEV-2 and later product implementation remain frozen.

2026-08-17 - DEV-1F Title Chrome Repaired

  • The fixed Title frame now uses a heraldic enamel guild header, ivory utility bridge and bottom command dock with layered gold trim, cut corners and procedural icons. New Game receives initial focus; Continue keeps a distinct disabled state and visible reason.
  • All six DEV-1 headless checks, including real parsed ScreenTouch, pass. A normal-render development matrix produced 20 frames at 760x360, 844x390 and 1280x720 across English/Chinese and 100/130% text with strict diagnostics 0.
  • Development capture root: /private/tmp/abg-dev1-title-dev-capture-2. It guides the visual repair but is not source-bound candidate evidence and does not grant human acceptance.
  • No image-generation calls were made. DEV-1G may extend only this proven UI grammar to Boot, first launch, Settings and Credits after DEV-1F is pushed.

2026-08-17 - DEV-1G Entry Pages Repaired

  • Boot now uses a compact verification deck with named progress; first launch uses an edge-attached setup panel; Settings and Credits use one enamel workspace with ivory selected segments, value plates and explicit toggle, slider, disabled and primary-command states.
  • The first development render exposed a setup GridContainer width regression and incorrect unselected-tab text state. That attempt was rejected; the controls gained real expansion sizing, the state binding was repaired and the same matrix was rerun.
  • Final local checks: all six DEV-1 headless markers, real parsed ScreenTouch and 20 normal-render frames pass with strict diagnostics 0. Development capture root: /private/tmp/abg-dev1-entry-pages-dev-capture-5.
  • The development capture is not source-bound candidate evidence and does not grant Owner visual acceptance. No image-generation calls were made; DEV-2 and all human/device/package/release gates remain open.

2026-08-17 - Revised DEV-1 Candidate Verified

  • Candidate product source: d3b93268776b87b7bfb407c79165011facc438f8.
  • Revised source-bound DEV-1 attempt: /private/tmp/aetherbound-guild-test-evidence/dev1-candidate-revised/20260817T091805Z-82593; PASS with archive SHA-256 980ad2fc2e2b0b667e2d2a46dec84320aaca6959755f1f524ee8e5835c85451e. It covers six headless behavior checks, real parsed ScreenTouch and 20 normal-render frames across 760x360/844x390/1280x720, English/Chinese and 100/130% text with strict diagnostics 0.
  • Revised preserved-system regression: /private/tmp/aetherbound-guild-test-evidence/dev1-fg4-regression-revised/20260817T092203Z-85944; PASS with archive SHA-256 d54963d22411165ad97ea31d256292701670a7cddd339f43d672c88e1b53f56a. All 30 Godot checks, five Python/media/audio checks, Save-v11, five-profile midpoint simulation, parsed touch and 24 legacy normal-render frames remain unchanged with strict diagnostics 0.
  • Source-bound entry frames were inspected at actual play size and reach only agent_visual_reviewed: enamel/ivory/gold hierarchy is coherent, selected, focused, disabled and value states are readable, and required 130% layouts do not overlap. Human visual/comprehension acceptance remains open.
  • No paid image calls were made. Device, packaging, signing, store and release gates remain open and were not exercised.

2026-08-17 - Continuous Initial Company Model Approved

  • The Owner confirmed Aetherbound Guild as a continuous-growth incremental game. New Game's four-offer choose-two draft establishes the persistent initial Expedition Company.
  • A Contract run remains a bounded expedition, but Contract completion retains recruited characters, individual levels/XP, Professions, Traits, equipment and the continuing roster instead of archiving and replacing it.
  • Zero HP removes a Recruit only from the current battle. That Recruit remains owned and returns for the next stage; permanent death and death-funded Replacement Credit are superseded product rules.
  • DEV-2 implements only initial-company creation. Existing FG-4 casualty, run closure, economy and Save-v11 code remains preserved historical behavior for a later player-order conversion and must not be silently presented as already compliant.

2026-08-17 - DEV-2A Continuous-Growth Authority Corrected

  • All six current authorities now define the one-time four-offer choose-two as creation of the persistent initial Expedition Company, followed by a Guild handoff rather than immediate per-run roster creation.
  • A zero-HP Recruit remains owned, leaves only the current battle and is battle-ready again at the next stage with the same stable identity and growth. The exact returned HP amount is intentionally deferred to the later balance conversion because the Owner approved return, not a specific full-heal value.
  • Contract clear or withdrawal retains Recruits, level/XP, Professions, Traits, equipment, history and persistent resources. Old permanent-death, Replacement Credit, Company-collapse and roster-archive detail is explicitly FROZEN_LEGACY_FG4, not current product authority.
  • ABG_PREDEVELOPMENT_DESIGN_SELF_TEST_OK cases=7, ABG_RECRUIT_LOADOUT_LEVEL_OK and git diff --check pass. No runtime code, Save-v11 behavior, media, package or release state changed in DEV-2A.

2026-08-17 - DEV-2B Stable Initial Draft Activated

  • Authority-correction source dd190477684e1eb2279a81645f2ccbc82373ea25 is pushed, clean and equal to upstream.
  • DEV-2B owns only the draft service/store and focused tests: one durable seed, four deterministic complete offers in fixed positions, zero-to-two selected IDs, restart-safe loading, no reroll and explicit invalid/corrupt recovery.
  • Player-facing choice UI, persistent Company commit, Guild/Market behavior, gameplay conversion, media production and delivery remain frozen.

2026-08-17 - DEV-2B Stable Initial Draft Implemented

  • runtime/entry/initial_company_draft_service.gd reserves one 128-bit seed and projects the verified opening Recruit generator into the current one-time Initial Company schema without persisting a Contract or current_run.
  • Each draft contains exactly four hashed offers in fixed positions with unique offer/Recruit IDs, generated name components, appearance seed, base Profession, equal-budget numeric attributes, exactly one Trait benefit/cost, one starting item state, level 1 and XP 0.
  • Atomic primary/backup/candidate handling preserves the same seed, offer order and zero-to-two selected IDs across restart. Duplicate, unknown and third selection inputs mutate nothing; invalid replicas return a named error instead of rerolling.
  • Focused Godot marker: ABG_DEV2_DRAFT_OK created=true offers=4 restart=true no_reroll=true selected=true invalid=true backup=true no_company=true. DEV-2C and later runtime/UI boundaries remain frozen until a separate pushed activation commit.

2026-08-17 - DEV-2C Recruit Choice Activated

  • Stable-draft source b337739336ba7e67484c004bb0b68a0ce8775ef1 is pushed, clean and equal to upstream.
  • DEV-2C owns Title navigation, the four-candidate choice page, Inspect, Compare A/B, independent selection, exact selected-count gating, Back and restart-safe page restoration plus focused headless/touch/layout evidence.
  • Company review/commit, the Guild handoff, DEV-3+, gameplay conversion, new media production and delivery remain frozen.

2026-08-17 - DEV-2C Recruit Choice Implemented

  • Title's New Game action now reaches a real Godot Initial Expedition Company page using the accepted painted entry environment and enamel/ivory/gold, cut-corner, heraldic runtime chrome.
  • Four equal offer plates expose stable name, base Profession, five attributes, Trait and selection state. Inspect shows Profession job, exact Trait benefit/cost and starting item; Compare A/B changes no selection.
  • Independent Select controls persist through the draft service. 0/2 and 1/2 disable Review with a reason, 2/2 enables it, and a third candidate is rejected without automatic eviction. Back and restart retain IDs, order and selection; corrupt data provides Retry and Title return without reroll.
  • Focused markers ABG_DEV2_CHOICE_OK and ABG_DEV2_CHOICE_TOUCH_OK pass with all six applicable DEV-1 markers. Development normal-render root: /private/tmp/aetherbound-guild-test-evidence/dev2-choice-development-dirty-v2; 16 frames cover choice, selected, inspect and compare across required sizes, languages and 100/130% text. This dirty-tree matrix is visual guidance, not source-bound candidate evidence or human acceptance.

2026-08-17 - DEV-2D Review, Commit And Handoff Activated

  • Choice-page source 50f53d882adf16395b2e5697867f11a776ae6c52 is pushed, clean and equal to upstream.
  • DEV-2D owns selected/unchosen review, same-draft Revise, exactly-once persistent Company creation, restart/duplicate handling and a bounded Guild handoff whose later actions state their unavailable reason.
  • Market, Contract selection/play, gameplay lifecycle conversion, new media, device packaging, stores and release remain frozen.

2026-08-17 - DEV-2D Review, Commit And Handoff Implemented

  • Review names the selected pair and both unchosen provisional offers. Revise returns to the same saved draft and selection; Create Company promotes only the selected two Recruit records to persistent owned state.
  • The independent Company file uses verified primary/backup/candidate writes and a deterministic exactly-once receipt. Duplicate commit returns the same receipt, interrupted candidates recover, matching lingering drafts are cleaned, and neither unchosen offers nor a Contract/current-run reset enter persistent Company state.
  • Successful creation and restart reach a bounded Guild handoff showing the two persistent members. Title disables New Game and enables Continue; Settings returns to Guild, while Contract Board and Market remain disabled with visible reasons instead of silently implementing DEV-3.
  • Focused markers ABG_DEV2_COMMIT_OK and ABG_DEV2_COMMIT_TOUCH_OK pass with all six applicable DEV-1 and all earlier DEV-2 markers. Development normal-render root: /private/tmp/aetherbound-guild-test-evidence/dev2-commit-development-dirty; 24 frames cover choice, selected, inspect, compare, review and Guild across required sizes, languages and 100/130% text with strict diagnostics 0. This dirty-tree matrix is guidance, not source-bound candidate evidence or human acceptance.

2026-08-17 - DEV-2E Initial Company Candidate Activated

  • DEV-2D source 71f49a4926499ec8aa4911f9d162df709ecf132f is pushed, clean and equal to upstream.
  • DEV-2E owns only source-bound complete DEV-2, applicable DEV-1, preserved FG-4, parsed-input, normal-render and strict-diagnostic evidence plus the final checkpoint/ledger closure.
  • Market, Contract selection/play, DEV-3+, gameplay lifecycle conversion, new media, device packaging, stores and release remain frozen.

2026-08-17 - DEV-2 Initial Company Candidate Verified

  • Candidate product source: d1990538d5d70059f1203bf4817d1b0e9bf49a74.
  • Source-bound DEV-2 attempt: /private/tmp/aetherbound-guild-test-evidence/dev2-initial-company-candidate/20260817T113907Z-96869; PASS with archive SHA-256 4593256c794c0f74f8a7f88fec9300652e520772f664f3b808ae6006c6e3035d. It covers six applicable DEV-1 checks, six DEV-2 checks including the complete parsed ScreenTouch player journey, and 24 normal-render Initial Company frames across 760x360/844x390/1280x720, English/Chinese and 100/130% text with strict diagnostics 0.
  • Preserved-system regression: /private/tmp/aetherbound-guild-test-evidence/dev2-fg4-regression/20260817T113949Z-99041; PASS with archive SHA-256 f434adb15ed8455cded7da691f91e1352316942d8bbf22065e2f9ff78d2dcbf1. All 30 Godot checks, five Python/media/audio checks, Save-v11, five-profile midpoint simulation, parsed touch and 24 legacy normal-render frames remain unchanged with strict diagnostics 0.
  • Source-bound choice, Review and Guild frames were inspected at actual play size and reach only agent_visual_reviewed: the four equal candidates, selected pair, unchosen-offer consequence, persistent-growth promise and disabled Guild reasons are readable without overlap at the required layout matrix. Human choice/comprehension/visual acceptance remains open.
  • No image-generation or paid media calls were made. Device, packaging, signing, store and release gates remain open and were not exercised.

2026-08-17 - DEV-2F Character-Forward Visual Repair Activated

  • Owner review rejected the source-bound candidate's visual balance: repeated enamel plates and text dominate while Recruit identity is absent. Functional choose-two, persistence, recovery and Guild boundaries remain preserved.
  • DEV-2F first uses the four existing non-pixel hand-drawn actor sources to prove character scale, crop, hierarchy and touch composition. Only after that runtime graybox passes may two regular 2x2 image calls add the eight missing base-Profession sticker sources within the standing task ceiling.
  • The repair owns person-bearing choice buttons, portrait-led Inspect/Compare/ Review, the persistent pair standing in Guild and illustrated but still disabled Contract Board/Market props. Battle animation, later Recruits, regions, DEV-3 behavior, package and release remain frozen.

2026-08-17 - DEV-2F Character-Forward Runtime Implemented

  • The four accepted non-pixel actor sources remain mapped to PF-B01, PF-B04, PF-B05 and PF-B07. Two authorized 2x2 gpt-image-2 calls added only PF-B02, PF-B03, PF-B06, PF-B08, PF-B09, PF-B10, PF-B11 and PF-B12; task IDs are task_01M07V8260ZYFZB7W4B7KCFEH2 and task_01M07VBKAXVYXPMDXFNVE352R2, total recorded cost $0.028.
  • docs/prototype/generation/dev2_character_stickers_01/asset-manifest.json records prompts, raw sheets, provider reports, hashes, edge-connected key removal, closed-hole cleanup, boundary despill and the eight runtime imports. The generated outputs are project-authored; human/device/release flags remain false.
  • Choice now presents four distinct Recruits as the dominant clickable controls over the shared painted environment. Inspect, Compare and Review keep those same identities visible; the committed persistent pair stands in Guild. Contract Board and Market use illustrated object stickers while their real disabled reasons and frozen DEV-3 boundary remain unchanged.
  • Focused worktree attempt /private/tmp/aetherbound-guild-test-evidence/dev2-character-worktree-suite/20260817T130943Z-23198 passes all six applicable DEV-1 and all six DEV-2 behavior/parsed-touch markers with strict diagnostics 0. Normal-render attempt /private/tmp/aetherbound-guild-test-evidence/dev2-character-captures/20260817T130637Z-20886 passes 24 choice/selected/Inspect/Compare/Review/Guild frames across 760x360, 844x390 and 1280x720, zh_CN/en and 100/130% text.
  • Six representative Godot runtime frames were delivered to the Owner for review. This reaches agent_visual_reviewed only; Owner visual/comprehension, device, packaging, store and release gates remain open. Source-bound DEV-2 and preserved FG-4 regression still gate DEV-2F closure.

2026-08-17 - DEV-2F Open-Stage Correction

  • Source-bound commit 9b8a533d86e041c4543e94a10ce42fd7438e9077 passes the complete DEV-2 candidate suite at /private/tmp/aetherbound-guild-test-evidence/dev2-character-candidate/20260817T132045Z-34538 with six DEV-1 markers, six DEV-2 markers, parsed input, 24 normal-render frames and strict diagnostics 0. Its evidence archive SHA-256 is d82750420c6ff7bcc9fc0daa59c184cf9f66b0d66fdb48576786823661fd76ce.
  • Owner comparison against the accepted battle-scale frame keeps the visual gate open: the actor set remains taller and more portrait-like than the unified compact Japanese 2D unit language, while the four vertical choice slots still read too much like cards.
  • The bounded graybox removes opaque full-height candidate plates, exposes one shared painted Guild scene and leaves only edge HUD strips, person controls, ground selection rings, names and commands. Worktree normal-render attempt /private/tmp/aetherbound-guild-test-evidence/dev2-open-stage-captures/20260817T135149Z-71812 passes all 24 required layout frames; focused choice behavior also passes at /private/tmp/aetherbound-guild-test-evidence/dev2-open-stage-choice/20260817T135111Z-71314.
  • The first preserved FG-4 rerun reached the configured 600-second attempt timeout during its later headless tests; no product failure was recorded. A macOS killpg EPERM then exposed a runner terminal-cleanup defect. Commit dd3b0cdb387c92b01773746ac14a30547e12e773 now records permission denial as a harness condition instead of throwing, and ABG_TEST_ATTEMPT_RUNNER_OK passes. The owned workspace and incomplete artifact were explicitly checked against their ownership marker and removed after confirming no process remained.
  • DEV-2F remains IN_PROGRESS. The Owner must review the open-stage screenshot before the remaining standing image allowance is used for a single unified compact-proportion Recruit family. DEV-3 behavior and all later gates remain frozen.

2026-08-17 - DEV-2F Unified Actor Family Authorized

  • The Owner clarified that actor art style, not only character presence, must remain consistent and asked whether the current display scale is too large. Agent review agrees: four reused sources and eight first-pass sources differ in line weight, face construction, body proportion, cel-shadow density and costume detail; the 1280x720 choice actors also dominate too much of the shared scene.
  • DEV-2F will replace all 12 mixed sources in one regular 4x3 sheet so every base Profession shares one line/rendering/proportion/light contract while retaining varied silhouettes and role tools. The accepted battle frame controls only the original compact Japanese 2D unit language; current contacts control only Aetherbound role/tool identity. No names, costumes, layout or other expressive content is copied from outside project authority.
  • Two earlier calls cost $0.028. The next unified sheet may use one call; the fourth and final standing task call is reserved only for failed-cell repair. Choice-page display scale will reduce while Inspect remains deliberately larger. DEV-3 and later actor/content production remain frozen.

2026-08-17 - DEV-2F Unified Compact Actors Integrated

  • The first unified task task_01M0813TXQGV09SBEJVVAZRH5P produced one internally consistent 4x3 sheet for $0.014, but agent comparison rejected the full sheet: 6.5-7-head anatomy and ornate key-art density still diverged from the accepted ordinary field-unit language. Its prompt, provider report, raw sheet, contact sheet and rejection reason remain preserved.
  • The final authorized task task_01M08280KEEFDB3HPCTC0V9H3N used only the accepted battle-scale frame as a visual-language reference and produced all 12 base Professions together for $0.014. The accepted runtime family uses compact 4.5-5-head tactical anatomy, one warm-charcoal line hierarchy, one face construction, one cel-shadow budget, one material density and one upper-left light. Total DEV-2F image use is four calls and $0.056; the task ceiling is exhausted.
  • Deterministic 4x3 slicing, connected key removal, enclosed-key cleanup, despill, 512px export, hashes and contact generation pass marker ABG_DEV2_COMPACT_UNIT_PROCESS_OK with 12 outputs and zero border alpha. InitialCompanyArt now maps every base Profession to exactly one texture. Choice display is reduced while Inspect/Compare remain larger; Guild display is reduced further so the persistent pair retains environmental context.
  • Focused behavior PASS at /private/tmp/aetherbound-guild-test-evidence/dev2-unified-actor-choice/20260817T144520Z-42716. The 24-frame normal-render matrix PASS at /private/tmp/aetherbound-guild-test-evidence/dev2-unified-actor-captures/20260817T144542Z-42958 across 760x360, 844x390 and 1280x720, zh_CN/en and 100/130% text. Agent inspection finds one coherent actor family, complete tools/silhouettes and no control overlap at play size. This reaches agent_visual_reviewed only; Owner visual/comprehension, device, package, store and release gates remain open.
  • Source-bound commit 5700a84f9b5b230b35a6dc4a65ad477586871200 passed all six DEV-1 and six DEV-2 behavior checks, then the fresh-import normal-render process completed 18 frames and accumulated renderer work before the 1280x720 fixture. The 900-second runner terminal is TIMEOUT, not a product failure or PASS, at /private/tmp/aetherbound-guild-test-evidence/dev2-unified-actor-candidate/20260817T145351Z-58238; its complete process group and workspace were removed.
  • The 1280x720/en/130% fixture passes all six states alone in 3.7 seconds at /private/tmp/aetherbound-guild-test-evidence/dev2-split-capture-fixture-3/20260817T151341Z-77767. The candidate harness now gives each of the four viewport/language/text fixtures its own normal-render process and retains the same 24 unique files, layout assertions, exact markers and strict diagnostic scan. Product runtime behavior and visible states are unchanged.

2026-08-17 - DEV-2F Command Chrome Reopened

  • Owner review accepts continued work on the actor-forward pages but rejects their current command presentation: every action is still enclosed by the same heavy double-gold octagonal box, generic diamonds do not communicate Back/A/B/Select intent, and the continuous outer border makes the scene feel like a framed utility panel.
  • The narrow repair owns only DEV-2 procedural chrome and its layout: a light parchment return tab, compact differentiated A/B tools, asymmetric secondary and primary command signs with familiar state symbols, and open corner plus header/footer rails. Existing callbacks, disabled reasons, touch bounds, localization, Recruit art and DEV-3 boundaries remain unchanged.
  • While visual direction remains in Owner review, each iteration runs only the focused DEV-2 input check and six representative normal-render states. One complete source-bound DEV-2 and preserved FG-4 regression will run only after the visual boundary is accepted; the interrupted earlier FG-4 attempt is not a PASS and its runner-owned process group/workspace were removed.
  • Command-chrome candidate v2 is implemented without changing callbacks or page state. The continuous double-line enclosure is replaced by open corner ornaments and separated header/footer rails. Return uses a light parchment tab; A/B tools are compact markers; unselected/selected actions use plus/check semantics; Compare and confirmation use distinct familiar symbols and asymmetric single-line command silhouettes. Guild footer and disabled destination signs use the same hierarchy.
  • Focused choice behavior PASS in 1.6 seconds at /private/tmp/aetherbound-guild-test-evidence/dev2-command-chrome-choice/20260817T153507Z-918. Six 844x390/zh_CN/130% normal-render states PASS in 2.4 seconds at /private/tmp/aetherbound-guild-test-evidence/dev2-command-chrome-review-v2/20260817T153537Z-1291. Agent review caught and repaired duplicate A/B glyphs, unselected checkmarks and old Guild double-frame buttons before Owner delivery. Full regression was deliberately not run; human visual acceptance remains open.
  • Owner follow-up rejects the v2 frame and spacing while retaining the new button hierarchy. Removing the old double enclosure left the content and ornament on one shared rectangle: headings, status copy, actors and footer actions crowd the edge, and the four isolated corner strokes look unfinished. DEV2-I12 now requires a separate content inset inside one precise outer hairline with constructed corner fittings and top/bottom rails. The old source-bound DEV-2 suite subsequently completed PASS, but the visual source is superseded by this explicit Owner rejection and cannot close DEV-2F.
  • Frame/spacing candidate v3 keeps the differentiated v2 buttons and separates ornamental chrome from content layout. The frame owns the project safe area; a second safe rectangle adds inner left/right/top/bottom padding for all page layouts. A single precise cut-corner hairline, four filled corner fittings and aligned header/footer rails replace the sparse strokes without restoring a heavy double enclosure. The same construction applies to choice, Inspect, Compare, Review and Guild.
  • Focused choice behavior PASS in 1.5 seconds at /private/tmp/aetherbound-guild-test-evidence/dev2-frame-spacing-choice/20260817T154715Z-19139. Six 844x390/zh_CN/130% normal-render states PASS in 2.4 seconds at /private/tmp/aetherbound-guild-test-evidence/dev2-frame-spacing-review/20260817T154743Z-20697. Full regression remains deferred until Owner visual acceptance.

2026-08-17 - DEV-2F Final Candidate Accepted And Verified

  • The Owner reviewed frame/spacing candidate v3, answered OK and explicitly authorized continuation into DEV-3 through DEV-6. This records human review of the current DEV-2 visual direction and actor family; broader comprehension, fun, device, packaging, store and release acceptance remain independent and open.
  • Final DEV-2 product source: 4352e253a83ee9f3ce3bca6eac99c5e70691f989. Source-bound candidate attempt: /private/tmp/aetherbound-guild-test-evidence/dev2-frame-spacing-candidate/20260817T155546Z-29597; PASS with archive SHA-256 f30ba5ae6d89f9aaeca66267e1d03d4559ecf8ffeb54685c51aa23b785d1ca68. It covers six DEV-1 checks, six DEV-2 checks, parsed touch and 24 normal-render Initial Company frames with strict diagnostics 0.
  • Preserved FG-4 regression: /private/tmp/aetherbound-guild-test-evidence/dev2-final-fg4-regression/20260817T155717Z-30828; PASS with archive SHA-256 a61c9871e62194b7e9e8fbb97f4923dc3edd584327db3ef3b363330444f540ea. All 30 Godot checks, five Python/media/audio checks, five-profile simulation, parsed touch and 24 legacy normal-render frames pass with strict diagnostics 0. Both attempts removed their complete owned process groups and workspaces.
  • DEV-2F and DEV-2 are complete. Exact handoff: ABG DEV-2 candidate ready. DEV-3 requires a separately activated durable plan and cannot reuse this closure as authorization to skip its own focused commit boundaries.

2026-08-17 - DEV-3 Guild And First Market Activated

  • The Owner authorized autonomous sequential development through DEV-6 and requested one durable Goal plus a complete morning handoff. DEV-3 is the only active milestone; later milestones advance only after focused verification, commit and push of the earlier boundary.
  • DEV-3 stops after two separate first-Market Recruit transactions: the persistent Company advances from two to four owned Recruits, Line capacity remains four, and exact Coin advances from 52 through the two protected prices totaling 28 to 24. No offer is recommended and no combined purchase exists.
  • DEV-3A first adds one migrated authoritative Contract/Market state around the verified Company file. DEV-4 formation/risk, DEV-5 battle/result and DEV-6 second-cycle management remain frozen.

2026-08-17 - DEV-3A Contract Foundation Implemented

  • The existing Company store is now schema v2. A validated v1 Company migrates atomically in place while preserving Company ID, both original Recruit records and the DEV-2 creation receipt; no parallel run file is introduced.
  • One explicit operation creates the first CTR-R1-01 Contract and its fixed Market together: 52 Coin, Line capacity four, three level-1 base Recruit offers at 14 Coin each, four equipment offers and three battle offers. The Contract receipt, board and available IDs survive restart, duplicate confirm, backup recovery and interrupted-candidate recovery without rerolling.
  • Focused persistence PASS: /private/tmp/aetherbound-guild-test-evidence/dev3-contract-foundation-worktree/20260817T164403Z-82290. Focused DEV-2 draft and Company/Guild regression PASS: /private/tmp/aetherbound-guild-test-evidence/dev3-contract-dev2-regression-worktree/20260817T164330Z-80953. Both attempts completed strict diagnostics and full runner cleanup. DEV-3B is now the only active step; no Guild UI or purchase behavior changed in DEV-3A.

2026-08-17 - DEV-3B Guild And Contract Choice Implemented

  • Guild now names Contract Board as the available next action and keeps Market disabled with an exact precondition until Contract creation. The Contract page presents the persistent opening pair in the painted scene, one unlocked First Windglass Crossing, four explicit difficulty segments, exact 52 Coin/ Line-capacity-four consequence, Cancel and Create Contract.
  • Difficulty changes are transient. Cancel returns to the unchanged Guild; Create Contract performs the DEV-3A transaction once, then reaches a bounded Market handoff. Title/Continue and process restart resume that active Market, while returning to Guild exposes Market and prevents a second Contract.
  • Focused English/130%-text parsed-touch PASS with ten touches: /private/tmp/aetherbound-guild-test-evidence/dev3-guild-contract-worktree/20260817T165241Z-93846. The affected DEV-2 Company/Guild behavior and parsed-touch tests PASS at /private/tmp/aetherbound-guild-test-evidence/dev3-guild-dev2-regression-worktree/20260817T165220Z-93616. Strict diagnostics and runner cleanup pass; no Recruit purchase, formation, risk or battle state is created. DEV-3C is now the only active step.

2026-08-17 - DEV-3C Stable Market And Recruit Review Implemented

  • The bounded handoff is replaced by one real physical Market ledger. Recruit, equipment and battle segmented categories expose the exact persistent 3/4/3 board. No row is auto-selected or recommended; list activation only selects an offer and updates the attached context, never purchasing or committing risk.
  • Recruit context alone opens a separate review with the same stable offer ID, full unified figure, exact Profession/role, Trait benefit and cost, five rolled attributes, starting item/effect, level/XP/history, 14-Coin price and Company 2 -> 3 | Line capacity 4 consequence. Cancel restores the same row and focus. Equipment and battle inspection cannot invoke Recruit review.
  • Focused Chinese/130%-text parsed-touch PASS with seven touches: /private/tmp/aetherbound-guild-test-evidence/dev3-market-review-worktree/20260817T170042Z-99698. DEV-3B and affected DEV-2 prior-boundary regression PASS at /private/tmp/aetherbound-guild-test-evidence/dev3-market-prior-regression-worktree/20260817T170008Z-99159. Board hash, 52 Coin, two owned Recruits and zero hire receipts remain byte- stable through every inspection and restart. DEV-3D is now the only active step.

2026-08-17 - DEV-3D Atomic First Hires Implemented

  • Recruit review now exposes one exact Recruit · 14 Coin confirmation only while its stable offer remains available and fewer than two opening hire receipts exist. The Market list remains inspection-only. Success returns to the unselected ledger with a receipt strip; it never chooses the next offer.
  • Each transaction atomically appends one projected persistent Recruit, removes only that available offer, deducts 14 Coin and writes an operation/intent/ offer/board/resource/Company receipt in the same Company file. Duplicate operation, new-operation recovery retry, conflict, price mismatch, unavailable offer, interrupted candidate and restart paths cannot charge twice.
  • Focused domain plus English/130%-text parsed-touch PASS: /private/tmp/aetherbound-guild-test-evidence/dev3-hire-worktree/20260817T170953Z-12028. Eight touches complete two distinct reviews and receipts, visibly advancing Company 2 -> 3 -> 4, Coin 52 -> 38 -> 24 while Line capacity remains four; the third offer stays inspectable with a truthful opening-phase state.
  • DEV-3A/B/C and affected DEV-2 regression PASS at /private/tmp/aetherbound-guild-test-evidence/dev3-hire-prior-regression-worktree/20260817T171027Z-12400. Strict diagnostics and runner cleanup pass. DEV-3E source-bound candidate closure is now the only active step.

2026-08-17 - DEV-3E First Candidate Failed At 760x360

  • Candidate source a0918bc1f618dcd8c43a1bdf4dd524e117305173 passed all six DEV-1, six DEV-2 and four DEV-3 behavior/persistence/parsed- touch checks. The first normal-render fixture then found the Market footer at y=310, height 52, extending 2 px below the 760x360 viewport. The attempt is retained as FAIL, not a candidate PASS, at /private/tmp/aetherbound-guild-test-evidence/dev3-candidate/20260817T172105Z-25636.
  • The narrow repair reduces only short-screen Market header, category, row and footer heights. The same six 760x360/zh_CN/100% states now pass normal render and layout bounds at /private/tmp/aetherbound-guild-test-evidence/dev3-visual-fixture0-repair/20260817T172253Z-27023. DEV-3E remains active until a fresh committed source passes the entire matrix.

2026-08-17 - DEV-3 Guild And First Market Candidate Verified

  • Final DEV-3 product source: 0da89b848c87013038ffa39c49d451fb2da8e3d1. Source-bound candidate attempt: /private/tmp/aetherbound-guild-test-evidence/dev3-candidate/20260817T172359Z-27922; PASS with archive SHA-256 d6b09a763b23932a105bed08eea82a535502886fee52254f38041e7a8f785059.
  • The attempt covers all six DEV-1, six DEV-2 and four DEV-3 behavior, persistence and parsed-touch markers. Four isolated normal-render processes produce 24 unique Guild/Contract/Market/Recruit-review states at 760x360, 844x390 and 1280x720 across zh_CN/en and 100/130% text. Layout bounds and strict diagnostics pass; the runner removed its complete process group and source/HOME/cache/TMP workspace.
  • DEV-3 and DEV-3E are complete. Exact handoff: ABG DEV-3 candidate ready. Human visual/comprehension/fun, device, package, store and release gates remain OPEN. DEV-4 requires a separately activated durable plan and cannot infer those approvals from this local candidate.

2026-08-18 - DEV-4 Automatic Formation And Risk Activated

  • DEV-3 closure source 0b4921b6d8fb5a9d625beb8d856aff8d0e0c541a is pushed, clean and equal to upstream. One stale headless Godot process from the preceding development session was found during activation and its sole process group was terminated before DEV-4 product work began.
  • The Owner authorized sequential unattended development through DEV-6 with durable progress and a complete morning handoff. DEV-4 alone is active; DEV-5 battle/result and DEV-6 second-cycle management remain frozen until the prior milestone has focused verification, commits, push and closure.
  • DEV-4A owns only an in-place formation/risk foundation around the current Company file: deterministic auto-order, exact line semantics, atomic prepared snapshots and three stable risk projections. Runtime Party/risk pages and the battle transaction remain later substeps.

2026-08-18 - DEV-4A Formation And Risk Foundation Implemented

  • FormationRiskService extends the existing schema-v2 Company/Contract file only after both opening hire receipts exist. It derives a stable four-member front-to-rear order, position-0 threat relation, protection/reach/coverage facts and the steady/pressured/elite projections from the persisted 3/4/3 Market; no second run file or battle receipt is created.
  • Order preview and Reset mutate nothing. Save Order and readiness acceptance use separate operation/intent/receipt hashes and are idempotent across retry; malformed, duplicate, unknown, stale and conflicting inputs leave the prior Company hash unchanged. Backup and interrupted-candidate recovery preserve the complete foundation.
  • Focused domain PASS: /private/tmp/aetherbound-guild-test-evidence/dev4-foundation-worktree/20260817T173807Z-45819. Affected DEV-3 two-hire domain/parsed-touch regression PASS: /private/tmp/aetherbound-guild-test-evidence/dev4-foundation-dev3-regression/20260817T173818Z-46589. Both attempts have strict diagnostics 0 and complete runner cleanup. DEV-4B Party Line is now the only active step.

2026-08-18 - DEV-4B Party Line Implemented

  • The completed second hire now enables one real Establish Line command in Market; before that boundary the same visible control states the exact 4/4 requirement. Continue resumes Party Line once its in-place foundation exists.
  • Four unified Recruit figures stand directly in the painted scene on one rear-left to front-right cord. The rightmost actor is position 0; selecting an actor then a destination swaps them without drag and immediately updates target, protection, reach and coverage text. Undo, Reset and Back work, while uncommitted previews never change the stored Company hash.
  • Focused two-language, 130%-text parsed-touch PASS: /private/tmp/aetherbound-guild-test-evidence/dev4-party-worktree/20260817T175842Z-67702. Four normal-render review states PASS at /private/tmp/aetherbound-guild-test-evidence/dev4-party-capture-worktree/20260817T175724Z-66420. Affected DEV-3 hire regression PASS: /private/tmp/aetherbound-guild-test-evidence/dev4-party-dev3-regression/20260817T175842Z-67703. Save & Review remains visibly disabled with its DEV-4C reason; DEV-4C is now the only active step.

2026-08-18 - DEV-4C Readiness Snapshot Implemented

  • Save & Review now calls the foundation's atomic order transaction and opens a separate Readiness Review. The page freezes the exact four IDs, position 0, protection/reach/sustain/control coverage, first threat, no-auto-Reserve rule and next-stage knockout return; Revise reloads the saved line without losing it, and Accept Preparation writes one idempotent readiness receipt.
  • Accepted preparation remains in the same Company/Contract file with 24 Coin, the Market and all earlier receipts unchanged. It creates no battle receipt, risk commitment or simulation checkpoint. Continue after restart resumes the Readiness Review; the later Risk command is visibly disabled with its DEV-4D reason.
  • Focused English/Chinese 130%-text parsed-touch PASS: /private/tmp/aetherbound-guild-test-evidence/dev4-readiness-worktree/20260817T180235Z-73712. Formation, Party Line and DEV-3 hire regressions also pass at /private/tmp/aetherbound-guild-test-evidence/dev4-readiness-foundation-regression/20260817T180254Z-75238, /private/tmp/aetherbound-guild-test-evidence/dev4-readiness-party-regression/20260817T180318Z-77144 and /private/tmp/aetherbound-guild-test-evidence/dev4-readiness-dev3-regression/20260817T180254Z-75239. All attempts have strict diagnostics 0 and complete runner cleanup. DEV-4D risk selection is now the only active step.

2026-08-18 - DEV-4D Risk Selection And Commitment Implemented

  • Readiness now opens a region-attached Risk Board only after the preparation receipt exists. Three stable options render as one comparison band with distinct pressure marks, not a recommended card wall. No option is selected automatically; selection is local until its commitment preview opens.
  • The preview carries the exact accepted party snapshot and compares known threat, uncertainty, entry cost, Coin reward, recovery exposure and current coverage. Cancel returns to the same risk; restart returns to Readiness with no local risk selection. Begin Battle is a real disabled action with a visible DEV-5 boundary and does not create a battle receipt.
  • Focused English/Chinese 130%-text parsed-touch PASS: /private/tmp/aetherbound-guild-test-evidence/dev4-risk-worktree/20260817T181010Z-86834. Three normal-render risk states PASS at /private/tmp/aetherbound-guild-test-evidence/dev4-risk-capture-worktree/20260817T181010Z-86833. Button copy was shortened after the first render exposed 130% ellipsis; the replacement render has complete Readiness and Risk Board labels. DEV-4E formation/risk candidate closure is now the only active step.

2026-08-18 - DEV-4 Automatic Formation And Risk Candidate Verified

  • Final DEV-4 product source: 62db001e8915873bb0b7632cfe90dd40a847530f. Source-bound candidate attempt: /private/tmp/aetherbound-guild-test-evidence/dev4-candidate/20260817T182401Z-99737; PASS with archive SHA-256 615b7803c758e281f4f1342441e1c7d8e2426f6dbf73290d1aaeaf4d4f108bc9.
  • The attempt covers six DEV-1, six DEV-2, four DEV-3 and four DEV-4 behavior, persistence and parsed-touch markers. Four isolated normal-render processes produce 24 unique Market/Party/Readiness/Risk states at 760x360, 844x390 and 1280x720 across zh_CN/en and 100/130% text. Layout bounds and strict diagnostics pass; the runner removed its complete process group and source/HOME/cache/TMP workspace.
  • The first 760x360 development fixture found the three inherited Market category controls at 38 px. DEV-4E raised their stable touch height to 44 px; the same fixture and complete source-bound matrix pass after repair.
  • DEV-4 and DEV-4E are complete. Exact handoff: ABG DEV-4 candidate ready. Human visual/comprehension/fun, device, package, store and release gates remain OPEN. DEV-5 requires a separately activated durable plan and cannot infer those approvals from this local candidate.

2026-08-18 - DEV-5 Battle Result And Recovery Activated

  • DEV-4 closure source 6b8b4d4ca867456b56907f93d60fa40e123948fb is pushed, clean and equal to upstream; no owned test processes remain.
  • The Owner authorized sequential unattended development through DEV-6. DEV-5 is the only active milestone; DEV-6 Company management remains frozen until the first automatic battle, result and next-stage recovery candidate closes.
  • DEV-5A owns only an independently authored current battle receipt and deterministic event timeline around the accepted DEV-4 formation/risk state. Historical battle/casualty services remain preserved but cannot be used as current persistence authority.

2026-08-18 - DEV-5A Battle Foundation Implemented

  • BattleService consumes the exact accepted Party snapshot and one stable risk option to create a single idempotent battle receipt in the existing Contract. A second operation cannot replace it; every phase persists through the same redundant atomic Company store.
  • The deterministic first-battle timeline is exactly opening, telegraph, guard, ranged, magic, healing, damage, knockout and result. Pressured risk awards 27 Coin once (24 -> 51), records one victory for all four participants and one battle-local knockout for the exposed position-0 Recruit. No roster record is removed or replaced.
  • Next-stage recovery records one receipt, keeps all four stable IDs and their Profession/Trait/equipment facts, returns Contract status to Market and releases the old formation snapshot. Duplicate settlement/recovery cannot duplicate Coin or receipts; backup recovery preserves the terminal state.
  • Focused domain PASS: /private/tmp/aetherbound-guild-test-evidence/dev5-battle-foundation-worktree/20260817T183617Z-16166. DEV-4 foundation/risk and DEV-3 hire regressions PASS at /private/tmp/aetherbound-guild-test-evidence/dev5-foundation-dev4-regression/20260817T183633Z-17719, /private/tmp/aetherbound-guild-test-evidence/dev5-foundation-risk-regression/20260817T183633Z-17721 and /private/tmp/aetherbound-guild-test-evidence/dev5-foundation-dev3-regression/20260817T183633Z-17720. All attempts have strict diagnostics 0 and complete runner cleanup. DEV-5B Battle Opening/Live is now the only active step.

2026-08-18 - DEV-5B Battle Opening And Live Implemented

  • Risk Commitment now creates the real Battle Opening/Live page. The painted field keeps four compact actors in rear-left to front-right order, a visible enemy-facing contact corridor, disclosed first threat and the causal event rail projected from the DEV-5A receipt. Playback is automatic and deterministic; Pause/Resume and 1x/2x are observation controls, with no combat command prompt or back path after commitment.
  • Continue from a persisted Company with an active battle receipt returns to the same Battle page. The runtime test uses separate deterministic Companies for zh_CN and en at 130% text, parsed touch input, and verifies the knockout phase remains active before Result is enabled.
  • The first implementation used awaited SceneTreeTimer callbacks and exposed an ObjectDB leak when a Battle Shell was released during playback. Playback now owns a one-shot Timer child and invalidates its generation on tree exit; strict diagnostics are clean.
  • Focused PASS: /private/tmp/aetherbound-guild-test-evidence/dev5-battle-ui-fix/20260818T004251Z-65519. Marker: ABG_DEV5_BATTLE_UI_OK; parsed touch 6; strict diagnostics 0; runner cleanup removed the complete process group and workspace. DEV-5C Result/Diagnosis is now the only active step.

2026-08-18 - DEV-5C Result And Diagnosis Implemented

  • Battle Result now names the objective and outcome, exact 24 -> 51 Coin settlement, 27-Coin reward, 48 total XP, 16 XP per surviving Recruit, first decisive damage and the battle-local knockout identity before Continue. The compact causal summary expands into committed order, target, event hash and reward receipt details without adding combat choices.
  • Result settlement now keeps exactly the authored nine events instead of appending a duplicate result. Three surviving Recruits receive 16 XP each; the knocked-out Recruit receives zero XP and retains level, identity, Profession, Trait, equipment and battle history. A repeated settlement keeps Coin 51 and one settlement receipt.
  • The first 844x390/130%-text render placed Continue partly below the viewport because the full nine-line event list and expanded diagnosis raised the container minimum height. The first viewport now carries a four-node causal chain while technical detail remains expandable; parsed touch reaches Continue without shrinking type.
  • Focused English/Chinese 130%-text PASS: /private/tmp/aetherbound-guild-test-evidence/dev5-result-ui-worktree/20260818T013511Z-8975. Battle foundation, DEV-5B Battle UI and DEV-3 hire/Company regressions PASS at /private/tmp/aetherbound-guild-test-evidence/dev5-result-foundation-regression/20260818T013538Z-9336, /private/tmp/aetherbound-guild-test-evidence/dev5-result-battle-ui-regression/20260818T013538Z-9337 and /private/tmp/aetherbound-guild-test-evidence/dev5-result-hire-regression/20260818T013538Z-9338. All attempts have strict diagnostics 0 and complete runner cleanup. DEV-5D Knockout/Recovery is now the only active step.

2026-08-18 - DEV-5D Knockout And Next-Stage Recovery Implemented

  • Result Continue now opens Knockout Review. The page names each fallen Recruit's stable identity, Profession, Trait, level/XP, equipment ownership, current-battle absence and the explicit next-stage return rule. Acknowledge is a real committed-consequence action and never implies deletion or same-battle return.
  • Recovery is a separate review surface with the unchanged roster and one atomic recover_next_stage operation. Commit retains every Recruit ID, Profession, Trait, level/XP, history and equipment, changes Contract status to Market, removes stale formation state and records one retry-safe recovery receipt. Duplicate recovery returns the original receipt; restart resumes at next-stage Market.
  • Focused bilingual 130%-text parsed-touch PASS: /private/tmp/aetherbound-guild-test-evidence/dev5-recovery-ui-worktree/20260818T020349Z-31847. Marker: ABG_DEV5_RECOVERY_OK; parsed touch 8; strict diagnostics 0; runner cleanup removed the complete process group and workspace. DEV-5E first-cycle candidate is now the only active step.

2026-08-18 - DEV-5E First-Cycle Candidate Verified

  • Source-bound candidate source: 05f89ad7e14323d213287e52112ff927ef812f8d. Candidate attempt: /private/tmp/aetherbound-guild-test-evidence/dev5-candidate/20260818T025343Z-77825 with archive SHA-256 744149b5c3f5c7f0d0e4a52b7ee5e733321a5a94feee716e97a92d12fe673eca.
  • The fresh archive runs six DEV-1, six DEV-2, four DEV-3, three applicable DEV-4 and four DEV-5 markers. The historical DEV-4 risk-disabled marker is intentionally superseded by the real DEV-5 Risk -> Battle path. Four isolated normal-render processes produce 24 Battle Opening/Live, Result, Knockout, Recovery and next-stage Market states at 760x360, 844x390 and 1280x720 over zh_CN/en and 100/130% text. Parsed touch, 44px controls, no permanent death, next-stage Market and strict diagnostics 0 pass; the runner owns and removes the complete process group and source/HOME/cache/TMP/browser workspace.
  • Exact DEV-5 handoff: ABG DEV-5 candidate ready. Human visual, comprehension/fun, device, package, store and release gates remain OPEN. DEV-6 requires a separately activated durable plan.

2026-08-18 - DEV-6 Durable Plan Activated

  • DEV-5 is closed at the exact handoff ABG DEV-5 candidate ready. DEV-6 is now the only active milestone under a new durable plan; no DEV-6 product code was changed before this activation.
  • DEV-6A owns the next player-visible boundary only: restart at the recovered Market, inspect sourced equipment, commit one universal-slot purchase/equip, read individual level/XP and restart without duplicate Coin/equipment. Roster detail, dismissal, promotion, Artifacts, second Contract creation and the second battle remain later named substeps.

2026-08-18 - DEV-6A Company Growth Foundation Implemented

  • Market Equipment review exposes one sourced item effect, fit, tradeoff and price with four real wearer controls. Unaffordable offers disable every wearer with the exact required/current Coin reason; affordable offers commit one purchase/equip operation.
  • The transaction removes one stable offer, changes Coin 24 -> 6, writes one retry-safe equipment receipt, replaces one universal Recruit slot and returns the prior starting item to persistent Company inventory. It preserves every Recruit's stable identity and individual level/XP. Duplicate operations do not charge twice; changed operation/wearer, stale price, unavailable offer and insufficient Coin return explicit errors without partial mutation.
  • DEV-6A upgrades two obsolete DEV-2 invariants narrowly: a starting item may move from equipped to inventory, and Company revision now counts equipment receipts after Contract/hire creation. All other Company/Recruit validation remains strict.
  • Focused PASS: /private/tmp/aetherbound-guild-test-evidence/dev6-growth-worktree/20260818T035436Z-29672. DEV-2 creation, DEV-3 hire and DEV-5 recovery regressions PASS at /private/tmp/aetherbound-guild-test-evidence/dev6-growth-dev2-regression/20260818T035307Z-28768, /private/tmp/aetherbound-guild-test-evidence/dev6-growth-dev3-regression/20260818T035307Z-28767 and /private/tmp/aetherbound-guild-test-evidence/dev6-growth-dev5-regression/20260818T035307Z-28769. Strict diagnostics are 0 and runner cleanup is complete. DEV-6B Roster/ Recruit Detail is now the only active step.

2026-08-18 - DEV-6B Roster And Recruit Detail Implemented

  • Guild now exposes a real Roster command. Four stable member controls open a selected summary and Recruit Detail with name/ID authority, Profession, Trait, individual level/XP, current equipped item and battle history. Back returns through Roster to Guild without changing Company state.
  • Dismiss remains visible on both Roster and Recruit Detail and now opens the explicit DEV-6C consequence review; no silent or premature destructive action is present. Restart resumes the authoritative Market destination and preserves every Recruit fact.
  • Focused PASS: /private/tmp/aetherbound-guild-test-evidence/dev6-roster-worktree/20260818T040436Z-36560. DEV-6A growth and DEV-5 recovery regressions PASS at /private/tmp/aetherbound-guild-test-evidence/dev6-roster-growth-regression/20260818T040503Z-36960 and /private/tmp/aetherbound-guild-test-evidence/dev6-roster-recovery-regression/20260818T040503Z-36959. Strict diagnostics are 0 and runner cleanup is complete. DEV-6C Dismissal/ Contract Return is now complete.

2026-08-18 - DEV-6C Dismissal And Contract Return Implemented

  • Roster and Recruit Detail now open an explicit dismissal review. The review names the stable Recruit, Profession, Trait and current equipment, states the no-refund consequence, returns the equipped item to inventory and leaves Coin unchanged. Dismissal is restricted to an unfrozen Market and rejects the final live Recruit with an explicit disabled reason.
  • Market now exposes a separate Contract Return review. It clearly distinguishes voluntary withdrawal from Recruit dismissal, preserves Company members, Coin, levels/XP, equipment and history, and commits one retry-safe receipt to mark the Contract returned before handing back to Guild. A conflicting second Return operation is rejected without mutation.
  • Focused marker ABG_DEV6_RETURN_OK passes with explicit confirmation, equipment return, final-member disabled state, parsed touch and strict diagnostics 0 at /private/tmp/aetherbound-guild-test-evidence/dev6-return/20260818T042042Z-47775. DEV-6A growth, DEV-6B roster and DEV-5 recovery regressions also pass via the owned attempt runner with complete process-group cleanup. DEV-6D source- bound candidate verification follows as the final DEV-6 boundary.

2026-08-18 - DEV-6D Second-Cycle Candidate Verified

  • The source-bound candidate starts from the persistent four-member Company in the next-stage Market, inspects and commits one sourced equipment upgrade, reads the same roster and Recruit Detail facts, reviews voluntary Contract Return and hands back to Guild. It stops before new battle/content and does not introduce a second Contract, promotion or Artifacts.
  • Source-bound candidate source: 96173243765bc7fe897c13bafebf0affa8a033e6. Attempt: /private/tmp/aetherbound-guild-test-evidence/dev6-candidate-final/20260818T043605Z-66692 with archive SHA-256 7f06d4c89d75689c8851a585245149a1a8d4dc5791c598926aa5f20df3f61862. All DEV-1..5 and DEV-6 markers pass, with parsed touch, 24 normal-render states across the required landscape/localization/text-scale matrix and strict diagnostics 0. The runner removed the complete process group and workspace.
  • Exact handoff: ABG DEV-6 CANDIDATE READY. Human visual/comprehension/fun, device, package, store and release gates remain OPEN; no later product scope is activated by this candidate.

2026-08-18 - DEV-3V Content-Surface Visual Repair Candidate

  • DEV-1/DEV-2 Boot, Title and initial-choice presentation remain unchanged. DEV-3 Guild, Contract Board, Market, Recruit Review and post-hire Market now use the bright hand-painted field, an open scene frame, field-attached HUD rails and differentiated content commands. The Company/Save/hire semantics are unchanged.
  • Source-bound candidate source: e979af7aeb5de9aead65a13f65429120ad6578d2. Attempt: /private/tmp/aetherbound-guild-test-evidence/dev3v-candidate/20260818T053424Z-20989. All DEV-1/2/3 markers, parsed touch, 24 normal-render states and strict diagnostics 0 pass. The fresh-start H5 visual check is published at the Gallery share URL recorded in CURRENT_CHECKPOINT.md.
  • DEV-3V remains IN_PROGRESS until the Owner reviews the H5 visual result; DEV-4+ presentation work remains frozen.