# PROJECT_STATE Read this first. Then inspect the specific files mentioned before touching them. ## What this is CA Automator: a mature, working Python (stdlib WSGI, no framework) + MySQL/SQLite practice-management app for a Nepali chartered accountant, with a vanilla-JS offline-first PWA frontend. **Not** Laravel/PHP — that was the original build-prompt's assumption; corrected after inspection (see git history, first commits). Currently being generalized from a Nepal-only tool into a **country-aware ERP platform** (Nepal first, India/UAE next), per user instruction: extend the existing Python app in place, database strictly MySQL going forward. No rewrite. **This installation's database of record is MySQL** (`ca_automator` on `localhost`, cutover executed 2026-08-31, see `docs/mysql-migration.md`). `data/.env` sets `CA_DB_ENGINE=mysql`; `start.sh` sources it, so the real app reads MySQL by default now. `db.py` still supports `CA_DB_ENGINE=sqlite` and the test suite runs against it (fast, no external dependency) — that's test/dev-harness plumbing, not this installation's real data, which lives in MySQL only. **Remote**: `https://github.com/kreesa325737/ca-automator` (private), `main` tracked. Push normally from here on — `git push`. **Deployment to caautomator.com — prepared, blocked, not yet executed.** See `docs/cpanel-deployment.md` for the full procedure: cPanel/Passenger on the same shared hosting account (`kreesa` on `kush.mysecurecloudserver.com`) already running `billing.kreesa.com` and the `kreesa.com` demand platform. Blocked on an account-wide httpd vhost issue only the host (Nest Nepal) can fix — nothing on that account serves over HTTP at all right now, for any site. `run.py cron-tick` (a bounded one-shot substitute for the old always-running `run.py worker`, needed because Passenger has no persistent-process option) and a real MySQL-mode `cmd_backup()` (the old one was SQLite-only and had been silently failing every cycle since the 2026-08-31 cutover — a full week with zero automated backups until this was caught and fixed) are both done and tested. Decision already made: **migrate** the real local data to the new host, not a fresh install — once that migration completes, the Mac's local instance stops being the copy of record (see that doc's own final section for why two independently-writable copies would diverge). Also carries a Phase 1-3 ERP build (org structure, employees, task/workflow/ resource engines — see "Phase 1-3: org/people/task/workflow/resource engine" below) done against the *original* master-prompt's module checklist, once inspection showed the pre-existing app already covered most of the rest of it (clients, engagements, timesheets, billing, audit, documents...). ## Architecture (unchanged facts, don't re-derive) - `server/app.py` (11.3k lines) — all routes, WSGI app. - `server/engines.py` (5.7k) + `server/{acct,audit_execution,business,corporate, forensic,ipo,tax_advisory,tp}_engines.py` — calculation engines, mirrored line-for-line in `web/*.js` for offline parity. Keep both sides in sync when editing an engine. - `server/db.py` — data layer. Already dual-engine (`CA_DB_ENGINE=sqlite|mysql`, env vars `CA_MYSQL_HOST/PORT/USER/PASSWORD/DATABASE`). New columns go through `_NEW_COLUMNS` (dict keyed by table), applied idempotently by `init_db()` on both engines via `_migrate_columns()` — **never** hand-edit `schema.sql` / `schema_mysql.sql` for a column added after initial release; they're frozen historical snapshots, `_NEW_COLUMNS` is the source of truth for anything after. - `server/reports.py` — Excel (openpyxl) + Word (python-docx) builders. - 152-table schema. `tp_country` (already seeded with every ISO-3166 country, NP/IN/AE carrying real regulatory content) + `tp_regulatory_rule` (versioned, effective-dated, per-country rules) is a fully-built Jurisdiction Configuration Engine — built for Transfer Pricing, but structurally the pattern the Country Engine generalizes. Reuse it; don't build a parallel country table. - No ORM, no tests-by-default coverage of `app.py` routes — 262 tests exist, concentrated on engines/migrations/auth-adjacent modules (`server/tests/`). ## Completed - **Git repo initialized** (`git init`, baseline commit `30060de`). `.gitignore` excludes `venv/`, `data/*.db*`, `data/.env`, `data/cred_enc.key`, logs. This repo had no version control before — always work from commits now, the baseline commit is the recovery point if anything here needs undoing. - **Country Engine, first slice**: - `rate_master.country_code` and `firm.country_code` columns added via `_NEW_COLUMNS` in `server/db.py`, default `'NP'`. Backward-compatible: every existing row backfills to `'NP'`, so nothing already using `db.rates()`/ `db.rate_dict()` changes behavior. - `db.rates()` / `db.rate_dict()` gained an optional `country_code="NP"` kwarg that filters `rate_master` by country. Old call sites (36 across engines.py/app.py/site_chat.py/ca_assistant.py/tax_advisory_engines.py) untouched, still get Nepal data. - New `server/country_service.py` — the intended single entry point going forward: `firm_country_code(firm_id)`, `country(code)`, `active_countries()` (currently NP/IN/AE — the three with real `tp_regulatory_rule` content), `rates(firm_id, ...)`, `rate_dict(firm_id, ...)`. Engines/routes should call through this, not `db.rates()` directly, once they're made country-aware. - Tests: `server/tests/test_country_service.py` (7 tests, all passing) + existing `test_db_migrations.py` (5) still passing. Full suite: 262 → now 269 passing after these additions. - **MySQL cutover rehearsed** end-to-end against a *copy* of the real database (never the live file) — schema init, full data migration (1,724 rows / 152 tables), row-count verification all clean. Real cutover steps documented in `docs/mysql-migration.md`. **Not yet executed for real** — that's a deliberate maintenance-window operation, not done silently. - **Six core engines (and every other rate_master-driven engine) are now country-aware**, via a request-scoped context rather than a new parameter on every engine function: - `db.py` gained a `contextvars`-based "current country" (`_current_country`, default `'NP'`), read by `rates()`/`rate_dict()` only when `country_code` isn't passed explicitly (their default changed from the literal `"NP"` to `None` → falls through to the contextvar). This is what actually makes `engines.py`'s ~15 `rate_dict(domain, fy, applies_to)` call sites — which take no country parameter of their own and were not touched — resolve against a non-Nepal country when asked. Covers *every* rate_master-driven engine (depreciation/salary_tds/business_tax/penalty/loan/lease, but also `dd_workbench`, `tds_deduction`, `vat_return` etc.), not just the six core ones — same mechanism, no extra work. - `country_service.use_country(code)` / `use_firm_country(firm_id)` — context managers that set/reset that contextvar. `app.py`'s four `engines.compute(...)` call sites (`/api/compute`, `/api/reports`, `client_directory`, `linked_workfiles`) now wrap the call in `with country_service.use_firm_country(u["firm_id"]):`. - The job-queue "report" path in `run.py`'s `run_jobs()` (queued/background report generation) does **not** yet wrap its `engines.compute(...)` call — its payload has no `firm_id` today. Still defaults correctly to `'NP'`, no regression, just not yet country-routed. Left for later. - Tests: `server/tests/test_country_service.py`, `UseCountryContextTests` (6 tests) — proves the context changes unparameterized lookups, restores on both normal exit and exception, and that an explicit `country_code` still overrides it. Full suite: 275 passing. - **`nepal_calendar` display output is now gated to Nepal firms**: - `engines._bs_label(ad_date)` — returns the Bikram Sambat label only when `country_service.current_country_code() == "NP"`, else `None`. Replaces the three unconditional `nepal_calendar.bs_approx(d)["label"]` call sites in `engines.py` (`_attach_dates`, `loan_schedule`, `lease_schedule`) — a non-Nepal firm's loan/lease schedule rows no longer carry a BS date that has nothing to do with its own calendar. - `db.get_current_country()` / `country_service.current_country_code()` — read-only peek at the same contextvar `use_country`/`use_firm_country` set, added alongside `_bs_label` since gating needed a getter, not just the existing set/reset. - **Deliberately NOT touched**: the `fiscal_year` table itself is structurally Nepal-BS-native (`label_bs`/`start_bs`/`end_bs` are all `NOT NULL`, no `country_code`), and `nepal_calendar.fy_label_for_ad()`'s own un-configured-date fallback derives a Bikram Sambat label. A firm with no `fiscal_year` row covering a given date — which today means every non-Nepal firm, since nothing populates country-appropriate rows yet — still gets a fabricated BS-style fiscal-year label internally (`engines.py`'s `_group_journals_by_fy`, used by `grant_accounting`). Fixing this properly means a real country-neutral Financial Period engine (the original master prompt's item #7), not a small gating change — left as its own future task, not silently folded into this one. - The two explicit `/api/calendar/bs-from-ad` / `/api/calendar/ad-from-bs` conversion endpoints in `app.py` are untouched — they're opt-in utilities a date-picker widget calls deliberately, not auto-injected into engine output, so there's nothing to gate. - Tests: `NepalCalendarGatingTests` (3 tests) — NP gets a label, IN gets `None`, and the no-context-at-all case (every pre-existing caller) behaves exactly as before. Full suite: 278 passing. - **India (`IN`) rate_master content seeded**, in `seed.sql`, right after the Nepal `tds` block. 22 rows, all `country_code='IN'`, `verification_status= 'UNVERIFIED'` (same convention as every Nepal row), `fiscal_year_label=NULL` (a standing rule — sidesteps the Financial Period gap above since it matches any `fy` value passed in). Verified end-to-end, not just present in the table: `personal_tax('individual', 1200000)` under `use_country('IN')` correctly computes ₹80,000 tax through the real new-regime slab structure (0%/5%/10%/15% bands), and `salary_tds` correctly resolves EPF through the *existing* `pf_employer`/`pf_employee` fallback path (Nepal's own non-SSF branch) — no new engine code needed for that part. - **Seeded**: `income_tax` individual slabs (new/default regime, Sec 115BAC(1A)), `income_tax` company rates (`company_rate_domestic_standard/ _concessional/_new_manufacturing/_foreign`, discovered dynamically by the existing `company_rate_` prefix mechanism — no engine change), `loss_ carry_forward_years` (8y, Sec 72), `health_insurance_cap` (Sec 80D, non-senior only), `payroll.pf_employee/pf_employer` (EPF 12%/12%), `tds` category rates (`tds_rate_contract/consultancy/commission/interest/ dividend/rent/royalty/nonresident` — India's TDS system is structurally the same category→rate shape as this domain already, unlike depreciation/ VAT/penalty below). `tds_rate_nonresident.value_num` is deliberately `NULL` (`'SOURCE REQUIRED'`-style, matching the existing convention already used for the same non-resident-payment uncertainty in the Transfer Pricing module's `tp_regulatory_rule` rows) — no single rate exists without knowing the payment type and any DTAA position. - **Deliberately NOT seeded** (full reasoning is a comment block at the top of the India section in `seed.sql`) — these need real *engine-shape* work, not just more rows, because India's actual mechanics don't fit the domain's current shape: - `depreciation` — Nepal's Schedule 2 pools are absorption-tranche-dated by BS month; India's Sec 32 block-of-assets system is a different mechanic, not just different rates. - `vat` — India's GST is multi-slab (0/5/12/18/28% + CGST/SGST/IGST split); this domain only has one `standard_rate` field. - `penalty` — Nepal's codes are literally section-numbered (`s117_.../s118_.../s119_.../s120_...`) to Income Tax Act 2058 provisions whose Indian analogues (234A/B/C/F, 270A) don't share the same amount/percentage/trigger shape. - Nepal-specific reliefs with no Indian equivalent at all (`remote_area_cap*`, `foreign_allowance_exempt_pct`, `ssf_rebate_slab1`, `female_rebate`, `senior_citizen_slab1_extra_pct`, `retirement_exempt_*`, `medical_credit_*`). - `donation_cap_pct`/`donation_cap_amount` (India's 80G is tiered 50%/100%-with/without-qualifying-limit by donee category — a single cap number would misrepresent how the relief works) and `retirement_deduction_cap` for 80C (a shared multi-instrument basket cap, not a retirement-contribution-specific one). - No `applies_to='couple'` rows at all for India — India has no joint/ couple filing status, unlike Nepal; this is a structural fact, not a gap. (`IndiaSeedDataTests.test_no_couple_status_seeded_for_india` guards this.) - Tests: `IndiaSeedDataTests` (7 tests) in `test_country_service.py` — correct slab tax computed via the real engine, no couple rows, company categories discovered dynamically, EPF resolves via the PF fallback, TDS categories present, the non-resident rate is deliberately unset (not guessed), every IN row is UNVERIFIED, and depreciation/vat/penalty have zero IN rows (so that gap is caught by CI, not rediscovered by surprise later). Full suite: 286 passing. - **`firm.country_code` is now settable from the admin UI**: - New `GET /api/admin/active-countries` (gated behind `site_settings`, same as the rest of firm-profile) — returns `country_service. active_countries()` (NP/IN/AE), not the full ~195-row `tp_country` reference list (that one's for a related party's *location*, not a firm's own jurisdiction — see `tp_country`'s seed comment). - `PUT /api/admin/firm-profile` now accepts `country_code`, validated against that same active-countries set (400 on anything else). Since the column is `NOT NULL`, an omitted/blank value keeps the firm's current country rather than failing the UPDATE — matters for an older cached frontend or a direct API call made before this field existed. - `web/app.js`'s `drawFirmProfile()` — a new "Country / jurisdiction" `` at the top of the Admin page, next to the existing FY switcher (`countrySwitcherHtml()`/`wireCountrySwitcher()` in `web/app.js`). Saves via a **new, dedicated** `PUT /api/admin/firm-country` endpoint, gated on `is_super_admin` (not the `site_settings` module grant, so it works regardless of a firm's module entitlements) — deliberately NOT reusing `PUT /api/admin/firm-profile`: that endpoint always rewrites all 14 of its fields from the request body (`b.get(f)`, missing fields → NULL), so posting just `{country_code}` through it blanked the firm's name/address/phone/socials and 500'd on `firm.name`'s `NOT NULL` constraint — caught live via Playwright against a scratch instance before it shipped, not assumed safe. On success: full `bootstrap()` refresh, `state.fy` set to the refreshed `current_fy` (see Financial Period fix below), `buildRail()` re-run. **UAE modules — all complete**, per explicit priority: - **VAT**: zero new code. `engines.vat_return()` only ever reads `vat.standard_rate` — exactly UAE's single 5%-rate shape. Just a `rate_master` seed. - **Corporate Tax** (0% to AED 375,000, 9% above): zero new engine either — it's `engines.personal_tax()`'s existing marginal-slab mechanic, called with `status='company'` against a `'company'`-scoped `income_tax` seed. Registered as the `uae_corporate_tax` lambda in `engines.ENGINES`. - **Penalties** (Cabinet Decision 49/2021, late-payment mechanics as revised by 108/2021): genuinely needed its own engine — fixed-AED / capped-% structure, nothing like Nepal's Sec 117-120 or India's 234A/B/C/F. New `server/uae_engines.py`, mirrored in `web/engines.js` for offline parity. - Both UAE-specific modules got **real module pages** (`web/app.js` `MODULES` dict, codes `CT`/`UP`) — unlike the India engines, which remain API-only (see "Not yet done" below). Live Playwright verification: nav visibility follows the country switch both ways, forms render, offline computation is correct (500,000 taxable income → 11,250 tax; a late-registration flag → 10,000 penalty; the 300% late-payment cap actually caps). - Applied to real production MySQL (backup taken first at `data/backups/pre_uae_seed_20260901_074238.sql`; verified client/user/ engagement/firm counts unchanged, `rate_master` grew by exactly the 14 new AE rows, both existing firms auto-granted the two new modules via `_grant_new_module_to_every_firm`). **Financial year now follows the country switch**: separate user report, mid-session — the FY pickers (global switcher, every module workfile's own picker, Transfer Pricing's picker) kept showing Nepal's Bikram Sambat `fiscal_year` table regardless of country, and the working FY never moved off whatever Nepali label was last set. Root cause: `bootstrap()` only ever exposed the Nepal-only table; nothing read the country-aware `financial_period` table the existing Financial Period Engine already builds periods for. Fixed with `fiscal_year_engine.financial_periods_for_firm(firm_id)` — returns the right table's rows (Nepal's own for a Nepal firm, `financial_period` for any other), normalised to the SAME `{label_bs, start_ad, end_ad, is_current}` shape `fiscal_year` already uses, so every existing FY picker and pro-ration lookup (`web/engines.js`'s `faFyWindow`/`fyLabelForAd`, used by Fixed Assets' day-based pro-ration) works unchanged — just fed correctly-scoped data via `bootstrap()`'s new `financial_periods` field, instead of always Nepal's. `ensure_periods_exist()` auto-seeds `financial_period` the first time a country with a known generation rule is actually needed, so the picker is never empty right after a firm's first switch to India/UAE. Live-verified: switching to UAE moved the FY from `2083-84` to `2026` (a 2024-2029 calendar-year spread, auto-seeded) everywhere at once; switching to India showed `2026-27`. **Accounting policy generator made country-aware too**: found while auditing for remaining Nepal-only text — `acct_engines.suggest_policies()` (the Accounting Automation module's policy-paragraph generator, output that ends up in an actual client deliverable) unconditionally cited "Nepal Financial Reporting Standards (NFRS)", "NAS 23/12/21" and "the Income Tax Act, 2058" in every generated paragraph, for every firm regardless of country. Now takes a `country_code` and cites the right GAAP (NFRS for Nepal, Ind AS for India, IFRS for UAE) and tax statute per country, via a `_STANDARDS` lookup — mirrored in `web/acct_engines.js`. The `AUDX_CHECKLIST_TEMPLATES` "NFRS Compliance" audit checklist in `app.py` (internal working-paper checklist, not a client-facing deliverable) still cites NFRS/NAS numbers unconditionally — lower-stakes than the policy generator, not fixed this pass, worth a follow-up (see below). **Organization & People, confirmed (not just assumed) UAE-ready**: zero `rate_master`/country coupling found in `org_engines.py`/`workflow_engine.py`/ `resource_engine.py` — branches, departments, teams, positions, employee profiles, skills, workflow rules all work identically regardless of firm country. `org_admin` is correctly absent from `MODULE_COUNTRY_APPLICABILITY` (applies everywhere). **Client-level country + logo**: `client.country_code`/`client.logo_path` (via `_NEW_COLUMNS`), `country_service.client_country_code()`/ `use_country_for_client()` resolve a client's own jurisdiction when set, falling back to the firm's — so a UAE-based firm with an India-incorporated subsidiary client computes that client's own workfiles under India's rules. `clientFormHtml()` in `web/app.js` has the country select + logo upload wired in. This was built earlier in the session (see git log around the same date) and re-confirmed still working this pass, not re-built. Tests: 5 (`is_module_applicable`) + 14 (`uae_engines`) + 6 (`financial_periods_for_firm`/`ensure_periods_exist`) = 25 new tests this pass. Full suite: 342 → 368 passing. ## Not yet done / next steps 1. ~~Actual MySQL cutover~~ — **done, 2026-08-31** (see above and `docs/mysql-migration.md`). Executed on explicit instruction. `data/.env` now sets `CA_DB_ENGINE=mysql`; the SQLite file remains as a pre-cutover backup only. 2. ~~Give `run_jobs()`'s "report" job payload a `firm_id`~~ — turned out to be moot: nothing in the codebase actually `INSERT`s into `job_queue` with `job_type='report'` anywhere (checked directly, no call site exists). That branch in `run.py`'s `run_jobs()` is unreachable scaffolding for a queued-report feature that was never wired to a UI trigger — not a live country-routing gap. Revisit only if/when something actually starts enqueueing that job type. 3. ~~The offline PWA has Nepal assumptions baked in~~ — **investigated and the real bug fixed, see "Offline PWA investigation" above.** Turned out to be a `bootstrap()`/`GET /api/rates` bug (always resolved Nepal regardless of firm), not a `web/engines.js` problem — that file already threads rates as a parameter, confirmed by loading it in Node directly. Remaining gap, real but scoped: `india_depreciation`/`india_gst_return`/ `india_interest_penalty` have no offline JS mirror at all yet (server-only). 4. ~~A real country-neutral Financial Period/fiscal-year engine~~ — **done, see "Financial Period Engine" above.** 5. ~~India: depreciation/VAT(GST)/penalty engine-shape work~~ — **done, see "India engine-shape work" above.** `india_engines.py`, callable via the existing `/api/compute`, 19 tests. Remaining gap: **no dedicated module-page UI** — these three have no `route`/nav link, only API access (granted, not yet wired to a form). Building that UI (dynamic block/line-item entry forms, matching the sophistication of e.g. the existing Depreciation module's pool editor) is its own substantial frontend task, not done here. 6. Every India rate_master value is an unverified placeholder, same as every Nepal one — needs review by someone qualified in Indian tax law before any client work, exactly like the Nepal banner already requires. Not something an AI session can complete on its own. 7. ~~The new Organization/Tasks/Calendar UI needs an actual browser click-through~~ — **done, same day** (see "Follow-up: actual browser verification" above). Installed Playwright into the scratchpad, drove the real UI, found and fixed two real bugs (a standalone task was permanently invisible; stale branch/department dropdowns). 19/19 checks passing, zero console errors. Not exhaustive though — task dependencies, subtasks, and editing an existing employee's profile were never clicked through; there is also no UI at all yet for `resource_engine.suggest_candidates()` (only `workload_report()`'s table is wired to a page). 8. `job_position.hierarchy_level` exists and is populated (default Managing Partner=0 → Intern=8) but **nothing reads it yet** — no approval-authority check, no "a reviewer must outrank the assignee" rule, no escalation logic. It's structurally ready for that (see the original master prompt's §6-7) but wiring it in is separate future work, not done here. 9. `schema.sql`/`schema_mysql.sql` are hand-kept in sync (`convert_schema.py`, referenced in a code comment, doesn't actually exist in this repo) — every new table this pass added was translated by a one-off script applying the same rules `db._mysql_column_decl()` already uses, then hand-reviewed and tested against a real MySQL database. Keep doing that for future tables; don't assume the two files can drift and be reconciled later. 10. Resource allocation (`resource_engine.suggest_candidates`) and workload are not offline-capable and have no UI test coverage beyond the API — same caveat as #7. 11. `workflow_rule.condition_json` only supports flat equality — deliberately, per its own docstring — but if a firm asks for "OR" or "greater than" conditions, that's a real, known ceiling, not an oversight to silently work around. 12. **India, deferred by explicit user instruction** ("we will think about India Later" — UAE was prioritized first, see "Country switcher + module-country-applicability + UAE modules" above). Still true from item 5: `india_depreciation`/`india_gst_return`/`india_interest_penalty` have API access only, no module-page UI and no offline JS mirror. Resume here when the user asks for India work specifically — don't self-initiate it. 13. `AUDX_CHECKLIST_TEMPLATES`'s "NFRS Compliance" checklist area in `app.py` still cites NFRS/NAS standard numbers unconditionally for every country — same class of bug as the accounting-policy generator fixed this pass, just lower-stakes (an internal working-paper checklist, not text that ends up in a client deliverable the way the policy generator's output does). Same fix shape would apply: key the checklist item text off `country_service.firm_country_code()` via a `_STANDARDS`-style lookup, same as `acct_engines._STANDARDS`. 14. The ~20 modules asserted "already country-neutral" (no `rate_master` dependency, confirmed by grep) were confirmed for computation shape, not spot-checked one-by-one through an actual UAE-context browser session the way VAT/Corporate Tax/Penalties were. Reasonable confidence, not the same standard of proof as the three modules that got live Playwright verification this pass. 15. UAE Corporate Tax's Small Business Relief election and free-zone Qualifying Income treatment (both of which can make the effective rate 0% regardless of the two-slab structure seeded) are not modelled — `uae_corporate_tax` always applies the standard mainland slabs. Called out in the seed.sql row's own `notes` column; a firm relying on either election needs to compute outside this module for now. ## Known constraints / house rules for this codebase - Every regulatory figure in `rate_master`/`tp_regulatory_rule` ships `UNVERIFIED` until a human checks it against the actual law — never mark something verified without being told to. - `schema.sql` is the single source of truth; `schema_mysql.sql` is *generated* from it (`convert_schema.py`, not inspected yet) — never hand-edit `schema_mysql.sql` independently for the original tables, only through `_NEW_COLUMNS` for anything added later (see above). - No test coverage assumption for `app.py` routes — manually verify route changes; the 262+ automated tests are concentrated in engines/db-migrations. - ~~**`rate_master`'s `UNIQUE (domain, code, fiscal_year_label, applies_to)` constraint does not include `country_code`.**~~ — **fixed, see "Country switcher + module-country-applicability + UAE modules" below.** `_fix_rate_master_dedup()` in `db.py` dedupes any existing collision then creates `ux_rate_master_dedup`, a COALESCE-based expression UNIQUE index that DOES include `country_code` (schema.sql's own constraint is untouched — frozen historical snapshot, per house rule above; this is a `_NEW_COLUMNS`-era migration layered on top, same as everything after initial release). Proven, not just asserted: UAE's seed rows share the same standing (`fiscal_year_label IS NULL`) `domain`+`code`+`applies_to` shape India already used (e.g. `income_tax`/`slab_1_ceiling`/`company`) — doesn't collide, precisely because `country_code` differs — and applied cleanly against real production MySQL with zero duplicate-key errors.