wushenghua/aetherbound-guild
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: align transferable lessons with generated recruits

Browse Source 
Co-Authored-By: Codex <noreply@anthropic.com>
This commit is contained in:
wushenghua
2026-08-11 09:43:18 +08:00
co-authored by Codex
parent 999034ae4f
commit 565ba2e050
1 changed files with 81 additions and 67 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference/TRANSFERABLE_STRUCTURE_LESSONS.md
+81 -67
View File
@@ -10,7 +10,8 @@ visual composition, art, animation, music, sound effects or source code.
Reference counts remain evidence about a captured build, not targets for this
project. Aetherbound Guild's scope comes exclusively from the [frozen product
contract][PRODUCT], while factual support comes from the [runtime census][CENSUS].
specification][PRODUCT] and [current game contract][GAME], while factual support
comes from the [runtime census][CENSUS].
## Evidence-To-Lesson Trace
@@ -20,7 +21,7 @@ contract][PRODUCT], while factual support comes from the [runtime census][CENSUS
| C-08 and C-09 | Enemy readability benefits from role-level telegraphing before commitment | Copying enemy identities, silhouettes, attacks or encounter compositions |
| C-10 through C-13 | Equipment and milestone rewards can change party behavior and contingency planning | Copying item or artifact identities, effects, rarity rules, prices or tooltip prose |
| C-14 and C-15 | Party order is a meaningful preparation decision | Copying a formation layout, slot count or exact battlefield mapping |
| C-16 through C-19 | Environment production and run progression need separate accounting | Treating asset families, victories, chapters and waves as interchangeable units |
| C-16 through C-19 | Environment production and run progression need separate accounting | Treating asset families, victories, progress markers and waves as interchangeable units |
| C-20 through C-23 | Collection, achievement and mode scope must be authored explicitly because the reference totals are unknown | Filling gaps with guesses from menu labels, scripts or assets |
| A-01 through A-08 | Layered presentation has a large and multi-category production footprint | Treating files, frames, types or component instances as gameplay content |
@@ -28,47 +29,50 @@ contract][PRODUCT], while factual support comes from the [runtime census][CENSUS
Aetherbound Guild should use the following independently authored loop:
`guild forecast -> roster and job plan -> equipment and formation -> route commitment -> readable auto-battle with bounded intervention -> causal result -> recovery or reward -> guild progression`
`contract forecast -> provisional Recruit selection or Market planning -> equip and order the Party line -> battle-offer commitment -> readable automatic battle -> causal result -> recovery or reward -> next Market or Guild progression`
The transferable lesson is the separation of player questions, not the
reference screen sequence:
| Boundary | Player question | Required state change | Required handoff |
|---|---|---|---|
| Guild forecast | What pressure is approaching, and what can I prepare for? | Threat and opportunity information becomes actionable | Opens roster, job, equipment and route planning without hiding constraints |
| Roster and job plan | Which people and capabilities form the expedition thesis? | Recruits receive explicit jobs and responsibilities | Formation and equipment previews expose consequences |
| Equipment and formation | What behavior, timing and position will each choice change? | Loadout and order create a testable battle plan | Route commitment summarizes the plan's known strengths and risks |
| Route commitment | Which uncertainty is worth accepting now? | Resources and risk are committed | Battle starts from a reviewable snapshot |
| Battle | Is the prepared plan working, and why? | The simulation resolves with sparse, legible intervention windows | Result view preserves the causal record |
| Result | What succeeded, where did the first failure begin, and what changed? | Rewards, injuries, losses and discoveries are explained | Recovery and progression actions are offered in context |
| Recovery or reward | How should the guild adapt rather than merely restore numbers? | The next plan gains a new option, constraint or tradeoff | Returns to forecast with a meaningfully changed decision space |
| Contract forecast | What pressure is approaching, and what can I prepare for? | Enemy families, boss rules, difficulty and reward breadth become actionable | Opens provisional Recruit selection or the stable Market without hiding constraints |
| Recruit and Market plan | Which generated offers add the needed capability under current Coin, capacity and recovery pressure? | Selection or hire commits a generated Recruit with a fixed Profession, one Trait and visible tradeoffs | Equipment and Party-line previews expose consequences |
| Equipment and Party line | What behavior, timing and order will each choice change? | Loadout and front-to-rear order create a testable battle plan | Battle-offer commitment summarizes known strengths, risks and failure exposure |
| Battle-offer commitment | Which disclosed risk is worth accepting now? | One seeded offer and its resources are committed | Battle starts from a reviewable snapshot |
| Battle | Is the prepared plan working, and why? | The deterministic simulation resolves without manual skill activation or in-battle reordering | Result view preserves the causal record |
| Result | What succeeded, where did the first failure begin, and what changed? | Rewards, Fallen Recruits, returned equipment and discoveries are explained | Recovery and progression actions are offered in context |
| Recovery or reward | How should the Company adapt rather than merely restore numbers? | The next plan gains a new option, constraint or tradeoff | Returns to the next Market or Guild with a meaningfully changed decision space |
This loop preserves anticipation, observation and diagnosis while giving the
original game its own guild-management framing, route logic and intervention
rules.
original game its own Company-management framing, Market economy and fully
automatic battle rules.
## Decision Timing
### Opening
The first interactive state should ask for a real build commitment using a
small, understandable option set. Onboarding may stage information, but it
should not make the opening plan on the player's behalf. The choice must expose
what changes in role, resource pressure or formation behavior.
The first interactive state should ask the player to select two of four
provisional generated Recruits before Run creation. Selection remains revisable
until commit, and the comparison must expose Profession responsibility, Trait
benefit and cost, rolled attributes, and Party-line implications. Onboarding
may stage information, but it must not make the opening plan for the player.
### Before Battle
Route, equipment, job and formation choices should converge in a plan review.
The review must show projected responsibilities and known threats without
pretending to predict the exact simulation. Reversible edits stay reversible
until commitment; destructive or costly changes require explicit confirmation.
Market, equipment, Profession, Party-line and battle-offer choices should
converge in a plan review. The review must show projected responsibilities,
known threats and exact failure exposure without pretending to predict every
simulation event. Reversible edits stay reversible until commitment;
destructive or costly changes require explicit confirmation.
### During Battle
Automatic execution is valuable only when cause remains inspectable. Each
bounded intervention should answer a distinct tactical question and preserve
the value of preparation. Slow playback, pause where platform rules allow, and
event inspection are diagnostic controls; they are not separate game modes.
Automatic execution is valuable only when cause remains inspectable. Battle
provides start, pause, speed, inspect and retreat controls, but no repeated
manual skill activation and no in-battle equipment or Party-line editing.
Playback and event inspection are diagnostic controls; presentation speed must
not change the deterministic result.
### After Battle
@@ -79,35 +83,36 @@ the next choice responds to what the player just learned.
### After Failure
Recovery must create a new viable plan without erasing consequence. Replacement
availability, injury handling, debt, route retreat and guild support should be
authored as economy rules. A platform-funded revival cannot be the balancing
assumption.
Recovery must create a new viable plan without erasing consequence. Fallen
Recruits remain removed for the Run, their equipment returns, death creates
Replacement Credit, and the next Market protects an affordable base-Profession
offer under the current product rules. Recovery must remain an authored economy
contract; platform-funded revival cannot be its balancing assumption.
### Persistent Progression
Persistent rewards should open new planning grammar: information, formation
options, profession transformations, route tools, recovery policies or
resource conversions. Flat universal bonuses may support progression, but
cannot carry it alone because they do not create a new decision.
Persistent rewards should open breadth: information, Profession sidegrades,
previews, challenges, catalog access and optional rule changes. They must not
grant permanent universal damage, health, Coin income or starting-capacity
advantages that replace Run decisions.
## Content Grammar
Every content row should declare its player-facing job before art production.
Every content row should declare its player-facing function before art production.
The following schemas are original planning requirements, not reconstructions
of reference data.
| Content family | Required differentiators | Filler rejection test |
|---|---|---|
| Recruit | Personal constraint, decision preference, formation responsibility, profession affinities, recovery consequence and relationship hook | Reject when swapping the name and portrait leaves every decision unchanged |
| Generated Recruit | Generated identity seed, modular appearance, fixed Profession, equal-budget rolled attribute distribution, exactly one Trait, equipment, level, price and offer provenance, survival history and recovery consequence | Reject any rule that treats a name or appearance combination as another gameplay identity or requires authored personal or social content |
| Base profession | Battlefield responsibility, resource verb, preferred position, readable cadence, failure mode and counterplay | Reject when it is only a stat package or element label |
| Advanced profession | A transformation of targeting, timing, position, resource flow or risk ownership | Reject when it is only a stronger version of the base profession |
| Enemy identity | Pre-commitment signal, threat rule, target pressure, counter, ally interaction, escalation state and result explanation | Reject when color or health is the only meaningful difference |
| Equipment or item | Eligible users, changed verb, trigger, tradeoff, positioning consequence, comparison rule and visible feedback | Reject when only a scalar value or rarity changes |
| Milestone relic | Build-level contingency, route-valuation change, conflict with other plans and a visible trigger | Reject when it is merely a larger generic bonus |
| Chapter | New route pressure, enemy grammar, economy stress, environmental rule, recovery question, boss synthesis and lasting guild consequence | Reject when it is only a visual reskin with larger numbers |
| Achievement | Explicit behavior worth recognizing, progress visibility, completion condition and non-distorting reward | Reject when it rewards passive repetition without teaching or celebrating mastery |
| Collection entry | Discoverability rule, readable unknown state, provenance, completion semantics and accessibility text | Reject when it exposes spoilers or exists only to inflate completion time |
| Regular advanced or hidden hybrid Profession | A transformation of targeting, timing, position, resource flow or risk ownership with declared prerequisites | Reject when it is only a stronger version of an existing Profession |
| Trait | One visible mechanical benefit and one cost that change offer, equipment or Party-line valuation | Reject when it is biography, flavor-only text or an unbounded extra rules bundle |
| Equipment | Eligible users, changed verb, trigger, tradeoff, order consequence, comparison rule and visible feedback | Reject when only a scalar value, rarity or presentation variant changes |
| Artifact | Run-wide contingency, Market or battle-offer valuation change, conflict with other plans and a visible trigger | Reject when it attaches as ordinary unit equipment or is merely a larger generic bonus |
| Ordinary or elite enemy | Pre-commitment signal, threat rule, target pressure, counter, ally interaction, escalation state and result explanation | Reject when color or health is the only meaningful difference |
| Boss | Contract-rule synthesis, phase and timeout logic, summon or displacement pressure, previewed counters and causal result needs | Reject when it is an ordinary enemy with only larger numbers |
| Region | New composition or Market pressure, formation-order valuation, environmental rule, recovery question and two-Contract escalation | Reject when it is only a visual reskin with larger numbers |
The matrices should distinguish an **identity** from its **presentation
variants**. Rarity, level, portrait expression, equipment overlay, animation
@@ -121,14 +126,14 @@ the underlying data model.
| Moment | Primary information | Secondary information | Deferred detail |
|---|---|---|---|
| Forecast | Route pressure, known threat, opportunity and deadline | Guild capacity and recovery exposure | Full historical statistics |
| Recruit or job choice | Responsibility gained, constraint accepted and team interaction | Growth path and equipment eligibility | Complete progression tree |
| Contract forecast | Region pressure, enemy families, boss rule, difficulty and reward breadth | Guild unlocks and recovery exposure | Full historical statistics |
| Provisional Recruit or Market offer | Profession responsibility, Trait benefit and cost, rolled attributes and Coin price | Party-line fit, equipment eligibility and offer provenance | Generated-name and appearance detail |
| Equipment | Changed behavior, eligible target, replacement result and resource cost | Synergies and comparison detail | Collection lore |
| Formation | Order, targeting exposure, protection relationship and movement implication | Alternate saved plans | Cosmetic presentation |
| Route commitment | Expected risk, reward class, uncertainty and irreversible cost | Relevant counters and recovery reserve | Unrelated collection progress |
| Battle | Current objective, dangerous cause, intervention availability and speed state | Aggregate team state | Long-form build explanation |
| Result | First collapse, decisive interaction, injuries/losses and earned choices | Contribution detail and event log | Meta collection celebration |
| Progression | New decisions unlocked and prerequisites | Long-term path preview and reset consequence | Unrelated branch detail |
| Party line | Front-to-rear order, target exposure, protection, reach and movement implication | Reserve options and predicted first interactions | Cosmetic presentation |
| Battle-offer commitment | Enemy order, risk tier, reward, retreat result and irreversible cost | Relevant counters and recovery reserve | Unrelated collection progress |
| Battle | Current objective, dangerous cause, pause/speed/inspect/retreat state | Aggregate Company state | Long-form build explanation |
| Result | First collapse, decisive interaction, Fallen Recruits, returned equipment and earned choices | Contribution detail and event log | Meta collection celebration |
| Meta progression | New breadth, information and challenge rules | Long-term catalog and mastery prerequisites | Unrelated history detail |
Tooltips must explain changed behavior in the same vocabulary used by battle
and results. Empty, locked, unaffordable, incompatible, full-capacity and
@@ -137,22 +142,29 @@ must carry meaning without relying on color, animation speed or audio alone.
## Approved Original Scope
These are direct, exact product-specification commitments, not observed or
inferred reference totals. Their authority is the [frozen product contract][PRODUCT].
These are direct product commitments, not observed or inferred reference
totals. Their authority is the [frozen product specification][PRODUCT] and
[current game contract][GAME]; stable identity namespaces are recorded in the
[content matrix authority][CONTENT].
| Original content family | Approved count | Evidence class and exactness | Planning consequence |
|---|---:|---|---|
| Named recruitable characters | 30 | Direct specification; exact | Each row needs a distinct personal constraint and build role. Shared rigs may support production, but identities cannot be palette variants. |
| Generated Recruits | Dynamic; no preset identity total or cumulative-hire cap | Direct specification; structural | Each Recruit is a compositional Run participant. Generated name and modular appearance do not create additional gameplay identities. |
| Base professions | 12 | Direct specification; exact | The base set must cover genuinely different responsibilities and resource verbs. |
| Advanced professions | 24 | Direct specification; exact | Each base profession receives authored transformations whose decision impact survives comparison. |
| Enemy combat identities | 100 | Direct specification; exact | Encounter design must compose rule interactions, not multiply visual variants. |
| Chapters | 8 | Direct specification; exact | Each chapter adds a decision grammar and culminates in a synthesis encounter. |
| Equipment and items | 320 | Direct specification; exact | Production should use coherent families while keeping each gameplay record traceable. |
| Behavior-changing equipment and items | At least 120 | Direct specification; lower-bound acceptance threshold | Validators must flag rows that change behavior, targeting, timing, positioning, resources or job identity and reject unsupported claims. |
| Regular advanced Professions | 24 | Direct specification; exact | Each base Profession has exactly two regular descendants whose decision impact survives comparison. |
| Hidden hybrid Professions | 6 | Direct specification; exact | Hybrid prerequisites and behavior must be discoverable and mechanically distinct; the full Profession catalog totals 42. |
| Mechanical Traits | 36 | Direct specification; exact | Every Recruit has exactly one lightweight benefit-and-cost modifier. |
| Equipment | 320 | Direct specification; exact | Production should use coherent families while keeping each behavior record traceable. |
| Artifacts | 60 | Direct specification; exact | Each identity changes shared Run valuation and remains distinct from unit equipment. |
| Ordinary and elite enemies | 100 | Direct specification; exact | Encounter design must compose rule interactions, not multiply visual variants. |
| Bosses | 16 | Direct specification; exact | Each boss synthesizes its Contract and exposes its distinctive rules before commitment. |
| Regions | 8 | Direct specification; exact | Each Region contains two ordered Contracts and two bosses and introduces a distinct pressure or valuation question. |
The reference census neither proves nor justifies these targets. It demonstrates
why gameplay rows and presentation assets need separate budgets. The original
contract remains the sole authority for scope.
why gameplay rows and presentation assets need separate budgets. The frozen
specification and current game contract remain the sole authorities for scope;
the content matrix records their stable IDs and currently requires at least 160
of the 320 equipment rows to change behavior rather than only a scalar.
## Production-Scope Implications
@@ -196,10 +208,10 @@ prove the workflow is designed.
### Budget Diagnostic Feedback
Auto-battle production scope includes more than attacks. It needs pre-commit
telegraphs, impact readability, misses and mitigation, status changes, death or
withdrawal, intervention readiness, speed-safe feedback and result causality.
Animation, VFX and audio budgets should map to these event roles before bulk
asset creation.
telegraphs, cast and impact readability, misses and mitigation, target changes,
projectile collisions, displacement, summons, status changes, casualties,
retreat, speed-safe feedback and result causality. Animation, VFX and audio
budgets should map to these event roles before bulk asset creation.
## Adopt, Adapt, Reject
@@ -207,9 +219,9 @@ asset creation.
|---|---|---|
| Adopt | Make pre-battle choices visibly affect automated outcomes and make results diagnostic | Author new rules, vocabulary and presentation for every state |
| Adopt | Use recovery to keep failure consequential but playable | Balance from the original economy, without platform-funded rescue assumptions |
| Adopt | Let persistent progression expand the planning space | Build an original graph, prerequisites, branch meanings and reset policy |
| Adopt | Let persistent progression expand the planning space | Open original breadth, information and challenge rules without permanent universal power |
| Adapt | Combine related preparation questions where it reduces navigation | Use an original information architecture; do not reproduce the reference arrangement |
| Adapt | Use milestone rewards as build pivots | Create original identities, triggers, conflicts and visual language |
| Adapt | Use Artifacts and fixed rewards as build pivots | Create original identities, triggers, conflicts and visual language |
| Adapt | Use modular asset production to control scope | Define original silhouettes, rigs, layers and animation grammar |
| Reject | File counts as evidence of gameplay breadth | Validate content matrices and asset inventories separately |
| Reject | Speed settings, tutorials or UI states counted as content modes | Define mode boundaries by rules, progression and failure contract |
@@ -220,8 +232,8 @@ asset creation.
The census should change downstream work in concrete ways:
- **Systems specifications:** define the full loop handoffs, intervention
boundary, failure recovery, persistence and save semantics.
- **Systems specifications:** define the full loop handoffs, automatic-battle
control boundary, failure recovery, persistence and save semantics.
- **Content matrices:** assign stable original IDs and the differentiator fields
above; maintain separate variant and asset references.
- **Screen/state map:** show decision-specific hierarchy, reversible and
@@ -251,7 +263,7 @@ answer yes to all of the following:
states?
- Are names, prose, formulas, values, layouts, trees, art and audio independently
authored?
- Does the result add a distinct job, counterfactual or information need rather
- Does the result add a distinct decision, counterfactual or information need rather
than a cosmetic variant?
Failure of any answer is an originality or completeness blocker during the
@@ -259,3 +271,5 @@ design-only stage.
[CENSUS]: REFERENCE_RUNTIME_CENSUS.md
[PRODUCT]: ../../.agent-taskgraph/spec.md
[GAME]: ../product/GAME_PRODUCT_CONTRACT.md
[CONTENT]: ../content/CONTENT_INDEX.md