IMPROVEMENT REPORT
Project: ASTRA: KALYUG PROTOCOL
Date: 2026-08-01
Author: Technical Director (Claude / Opus 5)
Status: RECOMMENDATIONS ONLY — nothing changed automatically
Companion documents: CONSISTENCY_REPORT_2026-08-01.md, ACTION_REQUIRED_2026-08-01.md
Every item below is justified, has an owner, has dependencies, and has an explicit reason it sits at its priority. Nothing here has been applied.
CRITICAL
Blocks other work. Cheap now, structurally expensive later.
I-01 — Resolve the progression question (in-match vs. account-persistent)
Refs: C-01 · Blocks: GDD, backend schema, Asset Manager, Weapon Manager, economy, ProjectOS data model Why critical: Every other system branches on this answer. Building ProjectOS's asset and weapon schemas before it is answered means building them twice. Recommendation: relics and runes are in-match only; account progression is cosmetic and title only; Karma is behavioural only. This is the only reading consistent with all eleven hard rules. Cost if deferred: schema rework across four ProjectOS modules and the entire backend.
I-02 — Fix the player count, then re-derive the netcode
Refs: C-04, R-02 · Blocks: map size, asset budgets, server cost model, netcode stack, the entire Tech Architecture Why critical: No number in this project can be estimated without it. It is also the input to the only recurring cost that scales with success (dedicated servers per CCU). Recommendation: decide the count first. Then price dedicated server-authoritative hosting at that count before confirming it. Treat "Unity Netcode" as provisional until this is done — NGO's client-hosted topology is a poor fit for large BR and conflicts with the Fair Gameplay pillar. Cost if deferred: a netcode rewrite at Alpha, which is the classic way projects of this type die.
I-03 — Write the Prana system, or delete the pillar
Refs: C-03 · Blocks: GDD, Character Manager, ability design, VFX pipeline, marketing position
Why critical: It is the project's stated differentiator and it does not exist. Without it, "mythology-first BR" is unsubstantiated.
Recommendation: write 06_ASTRA_Prana_System.md. Prana is the natural resource layer beneath abilities, the barrier system, and the mythology's mechanical expression. Do this before expanding the GDD, because most of the GDD hangs off it.
I-04 — Write the Cultural Design Policy before any character art
Refs: R-01 · Blocks: all character art, all skin monetisation, store listing, marketing Why critical: It is the highest-probability project-stopping risk, and it is nearly free to mitigate now and extremely expensive to mitigate after the art pipeline runs. Recommendation: a Bible section defining what may be depicted, what may be monetised, where inspired-by framing replaces direct depiction, and a named external cultural reviewer with sign-off authority at each character gate. Pay specific attention to Sita as a combatant and to selling cosmetics for Hanuman and Krishna.
I-05 — Write the Performance Budget document
Refs: C-05 · Blocks: ProjectOS Asset Manager (module 3), all art production, all outsourcing briefs
Why critical: Rule #1 is "Performance First" and there is currently no number to enforce it with. The Asset Manager literally cannot allocate per-asset budgets without a global one.
Recommendation: 05_ASTRA_Performance_Budget.md, locked and versioned: named worst-case device, triangle ceiling, draw-call ceiling, texture memory ceiling, per-character and per-weapon poly budgets, sustained-framerate/thermal policy, and APK + Addressables download-size ceiling.
I-06 — Confirm the ProjectOS hostname
Refs: C-08 · Blocks: deployment
Why critical: invert.aurionglobal.my is verified live today (302 at root, 200 at /legacy/). Deploying over it would replace a running pilot's front door.
Recommendation: deploy to astra.aurionglobal.my; leave Invert/Samudra alone. One Caddy block, zero risk.
HIGH
Needed before ProjectOS can do its job, or before Phase 1 starts.
I-07 — Define the Document & Entity ID contract
Refs: C-11 · Blocks: ProjectOS modules 2, 3, 10, 11
Why high: The Consistency Engine is the reason ProjectOS exists, and it cannot check references in a corpus with no reference format.
Recommendation: YAML frontmatter on every document (id, title, version, status: locked|draft|deprecated, owner, updated, supersedes); stable entity IDs (CHR-, WPN-, ZONE-, RUNE-, RLC-, AST-, AUD-, VFX-, UI-); [[ID]] cross-reference syntax. This one contract turns four ProjectOS modules from decorative into functional.
I-08 — Assign document ownership and forbid cross-writing
Refs: C-10 · Blocks: long-term consistency Why high: Ownership overlap already exists at 87 lines. It compounds. Recommendation: Bible = vision/rules/pillars (amendable only by versioned amendment). GDD = all systems and numbers. Tech Arch = engine/netcode/budgets/tooling. Production Bible = phases/gates/pipelines/schedule. Game modes move from Bible → GDD.
I-09 — Add an Ability Impact Budget as a hard rule
Refs: C-02 · Blocks: hero design, balance Why high: It converts "Gun skill wins" from a slogan into an enforceable constraint that a balance reviewer can fail a design against. Recommendation: cap ability damage as a percentage of max HP; forbid abilities from securing kills without a weapon follow-up; steer abilities toward mobility, information, denial and repositioning — which also serves Rule #5, "Identity over Power".
I-10 — Reconcile the silhouette and reuse rules, and add a test protocol
Refs: C-07 · Blocks: character pipeline, Character Manager schema Why high: The shared-skeleton pipeline actively works against silhouette differentiation. Discovering this after five characters are modelled means remodelling five characters. Recommendation: differentiate via non-skeletal attachments within a fixed poly allowance; keep skeleton and base body shared. Add the Silhouette Test: black-filled model, target screen size and distance, identified in one second by a fresh observer. Make it a pipeline gate in ProjectOS with a pass/fail field on every character asset.
I-11 — Give every production phase measurable exit criteria
Refs: R-04, C-06 · Blocks: ProjectOS Dashboard "Completion %", Milestone Tracker Why high: Without exit criteria, completion percentage is a number generated from nothing, which is worse than no number because it will be believed. Recommendation: rewrite the Production Bible so each phase carries entry criteria, exit criteria, deliverables, and a named gate decision. Add Phase 4 — Live Operations (C-13).
I-12 — Make "Audio Before Graphics" real in the pipeline
Refs: C-06 · Blocks: nothing yet — which is exactly why it is cheap to fix now Recommendation: give audio a Phase 0 deliverable (core weapon audio, hit confirm, kill confirm, footsteps) that must exist before the corresponding weapon art is commissioned. Otherwise amend Rule #4, because an unenforced hard rule devalues the other ten.
I-13 — Specify the backend, store and telemetry
Refs: R-02 · Blocks: monetisation, Tech Architecture completion Why high: For a cosmetics-only game, the entitlement and store system is the revenue system. Recommendation: a Tech Architecture section covering accounts, entitlements, IAP receipt validation, store, matchmaking, telemetry and anti-cheat — with an explicit line on which parts are UGS and which are custom.
I-14 — Drop hosted Supabase; use the Postgres you already run
Refs: C-09 · Blocks: ProjectOS build
Why high: A second database contradicts the project's own "single source of truth" rule and adds a vendor, a bill and an outage surface.
Recommendation: Next.js + TypeScript + Tailwind + shadcn/ui + Prisma → existing Contabo Postgres (dedicated astra schema and role, matching the isolation pattern already used across the estate), containerised behind aifh_caddy. The recommended stack survives essentially intact.
MEDIUM
Do before the content pipeline scales.
I-15 — Lock the title and write naming conventions
Refs: C-12 — full title, short code, bundle ID, plus conventions for assets, prefabs, materials, animation clips and git branches. Free now; expensive at asset #2,000.
I-16 — Define Karma precisely, or rename it
Refs: C-14 — behavioural only, zero combat and zero loot effect. The word invites a power reading; if it is not a power system, consider a name that does not imply one.
I-17 — Add the Meta Loop to the GDD
Refs: C-13 — Rule #8 mandates retention and nothing implements it. Session → reward → reason to return. Seasons, battle pass structure, and patch cadence.
I-18 — Write the missing gameplay definitions
Refs: R-05 — match length, TTK, circle rules, map size, inventory model, healing, Duo revives, damage model, recoil, aim-assist policy, ranked, comms. Each is a fork that changes assets, so each is cheaper before art than after.
I-19 — Write the capacity and scope plan
Refs: R-03 — estimate the asset count against the declared content (5 heroes, 10 weapon families, 10 zones), state the actual team, and confirm the scope is reachable. If it is not, cut zones before cutting quality. This is the single best argument for Rule #2 and for the Asset Manager's deduplication role.
I-20 — Write the edge-case and compliance policy
Refs: R-06 — disconnect/reconnect, AFK, team-kill, region/latency, low-storage devices, account recovery, refunds, age gating, and privacy compliance (India DPDP Act; Malaysian entity obligations).
I-21 — Record the Unity commercial terms
Refs: R-07 — capture the exact licensing and fee terms being committed to, with a mandatory review at every phase gate.
LOW
Quality-of-life and long-horizon.
I-22 — Version control and branching strategy for the Unity project
Git LFS policy, branch model, what is committed vs. generated, and how ProjectOS references commits. Needed before a second contributor, not before the first.
I-23 — Localisation architecture
No text is hardcoded, string tables from day one. Trivial now; a multi-week retrofit later. Given the target market this is more likely High than Low — flag for reconsideration once the market plan is written.
I-24 — Accessibility baseline
Colourblind-safe palettes, scalable UI, remappable controls, audio cues that do not rely on stereo alone. Cheap if designed in.
I-25 — Build and CI pipeline
Automated Android builds, versioning, artefact retention, and ProjectOS ingesting build metrics (size, framerate, crash rate) so the Dashboard's "Performance Metrics" panel has a real feed instead of a placeholder.
Recommended sequence
Gate A — decisions only (no code). I-01, I-02, I-03, I-04, I-06, I-14. Roughly a week of decisions. Six answers unblock everything.
Gate B — the contract (no game code). I-07, I-08, I-05, I-11. This is what makes ProjectOS functional rather than ornamental.
Gate C — build ProjectOS. Shell + real schema + document ingestion + Consistency Engine, deployed to the confirmed hostname. Populated with Action Required cards for every unanswered question, so the dashboard's first honest reading is "here is what this project does not yet know".
Gate D — write the game inside ProjectOS. Every subsequent document is authored in ProjectOS first, then flows outward. This is the operating discipline the whole project rests on.
Gate C is the deliverable you asked for. Gates A and B are what stop it from being an empty shell — and both are decisions rather than work, so they cost you time to think, not weeks of build.