t2000-engineering

t2000 Engineering Discipline

Merged 2026-07-24 from four Cursor rules that were alwaysApply: true (engineering-principles, goal-driven-execution, coding-discipline, product-build-algorithm). The load-bearing assertions live in CLAUDE.md § Engineering Discipline and apply every turn; this file is the depth behind them.

---

1. Trace the full path BEFORE writing code

Before fixing any bug, trace the ACTUAL execution path from user action → API route → handler → SDK → on-chain → response → UI render. Verify which functions/routes/ handlers are actually called. Never assume.

What went wrong once: spent 4 iterations fixing sdk.swap() balance-change parsing when the Audric web app uses a sponsored transaction flow (/api/transactions/prepare → sign → /api/transactions/execute) that never calls sdk.swap() directly. The fix needed to be in the client-side handleExecuteAction, not the SDK.

Checklist before implementing a fix:

1. What is the ACTUAL data flow? (trace it, don't guess)
2. Where does the data first become wrong? (that's where to fix)
3. Does this fix introduce duplication? (if yes, rethink)
4. Will this fix survive adding a new token/asset/feature? (if no, rethink)

2. Single source of truth — never duplicate

If data exists in one place, import it. Never copy token maps, decimal maps, or config into multiple files.

// ❌ BAD — hardcoded list that gets stale
const COMMON_TOKENS = 'SUI, USDC, USDT, USDSUI';

// ✅ GOOD — derived from canonical source
const { TOKEN_MAP } = await import('@t2000/sdk');
const supportedTokens = Object.keys(TOKEN_MAP).join(', ');

3. Ask "does this scale?" before every implementation

Before hardcoding any list, map, or constant: "Where is the source of truth? Can I derive this dynamically? Will someone have to manually update this when things change?" If the answer to the last question is yes, the approach is wrong.

4. Fix at the root, not the symptom

When a fix requires changes in 3+ places or multiple retry attempts, the architecture is wrong. Step back and find the single point of failure.