Technical decisions register¶
One row per decision, from a one-line choice to a full ADR. The ADR holds the long argument; this register holds the decision, its status and its evaluation on the five parameters (§1), so a reader sees in one place what was decided and why. The governance repo on GitLab keeps the programme-level decision register. This one covers the engineering choices made through MMDEP; rows that matter programme-wide are copied there by an agent with GitLab write access (never by MMDEP-PM, who is read-only on GitLab).
1. How every proposal is weighed (Atul, 24 Oct)¶
| # | Parameter | The question | How it's scored |
|---|---|---|---|
| V | Value and practice | Does it add value to our needs and become a useful part of the business or workflow? Is it good engineering practice? | H / M / L, with the business line it serves (R1 website, R2 renewals, harness, programme) |
| S | Simplicity | Does it simplify the workflow, complicate it, or leave usage and efficiency unchanged? | + simpler / 0 neutral / − more complex (what it adds or removes) |
| C | Cost and benefit | One-time cost (hardware, setup) and recurring cost (subscriptions, API, hosting); what it returns | ₹ one-time / ₹ per month; payback or value per sprint (roadmap v4 value model) |
| D | Data and security | Which data classes it touches, and where the data goes | Data classes (ADR-0009): public (anywhere), indicative (free tools allowed, no identifiers), internal (paid or ZDR tools; free only for public or synthetic parts), client (approved, paid, India-region only; never free tools, never outsiders) |
| L | Ethics and law | Which ethical or legal questions does it raise? | We include such features in the design and test them against use cases. Before building or using one, we get a quick legal opinion for the specific use case. Flag: none / check before build / blocked |
Practice (rules §22):
1. A decision isn't built until its row exists here, with V/S/C/D/L filled in.
2. Big decisions also get an ADR (docs/adr/); the ADR's "Evaluation" section repeats the five parameters.
3. The design check (B35, B43) fails a new ADR or LLD without that section.
4. Status values: proposed (awaiting Atul) · accepted · on hold · superseded by TD-n · rejected (reason).
5. A rejected idea stays in the register with its reason, so it isn't proposed again without new facts.
2. Decisions¶
Columns: V value · S simplicity · C cost · D data class · L legal flag. Source is where the argument lives.
Inherited from the Claude CLI sessions (spec 0.7 addendum A1–A14 and the Technology Evaluation, 27 Sep)¶
These were kept in the Claude project documents MMDEP-spec-0.7-addendum.md (the decisions made after spec 0.6) and Technology-Evaluation-2026-09.md (studies and top recommendations), written during the CLI sessions that built the mmdep CLI. They're brought into this register so there is one place to look; the evaluation's figures are as of September and need rechecking before any purchase.
| TD | Date | Decision (addendum id) | Status 24 Oct | V | S | C | D | L |
|---|---|---|---|---|---|---|---|---|
| TD-A01 | 27 Sep | Three engine types (online frontier, hosted open, local), each tagged with the data classes it may receive (A1) | accepted; lives on as routing by data class (TD-015) | H | + | ₹0 | all | none |
| TD-A02 | 27 Sep | TEA estate loop: estate register, ledger metrics, monthly and quarterly reports, decision-record triggers (A2) | partly built (collector, capacity register); reports not yet | H | 0 | ₹0 | internal | none |
| TD-A03 | 27 Sep | Document management: estate / project / contract layers, stable IDs, per-repo snapshots with a lock file, mmdep docs check (A3) |
partly superseded by TD-016 (MADR, C4, docs site); docs gaps built (B35) |
M | 0 | ₹0 | internal | none |
| TD-A04 | 27 Sep | Repository profile: origin and forge as configuration; hub state never in git (A4) | accepted | M | + | ₹0 | internal | none |
| TD-A05 | 27 Sep | App AI layer: per-app AI interface by data class; calculators as tools; regulatory review before any recommendation feature (A5) | accepted as a design principle | H | + | ₹0 now | client features in-region | check before build (SEBI advice vs distribution, IRDAI) |
| TD-A06 | 27 Sep | Docs-only changes skip build/test/deploy; servers get built artifacts (A6) | partly (docs job report-only) | M | + | saves CI minutes | internal | none |
| TD-A07 | 27 Sep | Environments: new apps main + tags; legacy env branches one-way (A7) | accepted (API lanes follow it) | M | + | ₹0 | internal | none |
| TD-A08 | 27 Sep | Forge feature matrix before building; also MkDocs, Uptime Kuma, gitleaks, Renovate (A8) | MkDocs and gitleaks done; matrix, Uptime Kuma, Renovate open | M | + | ₹0 | internal | none |
| TD-A09 | 27 Sep | Three-engine evaluation on the same ~15 tasks (A9) | replaced by per-model pass rates in the harness ledger (B2) and the Codex spike (TD-037) | M | 0 | ₹0 | internal | none |
| TD-A10 | 27 Sep | Gemini as fallback on a paid key, stable model (A10) | superseded: Gemini paid is now the default harness model (TD-007, TD-029) | H | + | small | internal | none |
| TD-A11 | 27 Sep | Google Drive publishing of snapshots (A11) | superseded by GitHub control/reports branches and the docs site (TD-026) | L | 0 | ₹0 | internal | none |
| TD-A12 | 27 Sep | Parallel development agents with own worktrees and identities (A12) | accepted (worktrees B20/B31; Sonnet, harness, Assistant) | H | 0 | ₹0 | internal | none |
| TD-A13 | 27 Sep | Online MCP gateway for browser agents (A13) | becomes the MMDEP hub on the server (TD-024 medium term) | H | + | server | internal | none |
| TD-A14 | 27 Sep | Test resource limits on the laptop (A14) | accepted (suite runs in CI; laptop runs are single) | L | 0 | ₹0 | — | none |
| TD-A15 | 27 Sep | Technology Evaluation top 3: measure before buying hardware; online-first, add engines on evidence; client-data AI hosted in India (e.g. gpt-oss on Bedrock Mumbai) | accepted; restated in TD-035 (three horizons) | H | + | ₹0 until evidence | client in-region | DPDP: check before build |
Earlier decisions (summarised from the ADRs)¶
| TD | Date | Decision | Status | V | S | C | D | L | Source |
|---|---|---|---|---|---|---|---|---|---|
| TD-001 | 28 Sep | Orchestrator code on GitHub (MMDEP); estate knowledge in the GitLab governance repo | accepted | H | 0 | ₹0 | internal | none | ADR-0001 |
| TD-002 | 05 Oct | Agent platforms: ChatGPT projects for project work, Claude for MMDEP and design | accepted | H | + | subscriptions only | internal | none | ADR-0002 |
| TD-003 | 05 Oct | Controller runs on the laptop now; cloud VM later | accepted | H | 0 | ₹0 now | internal | none | ADR-0003 |
| TD-004 | 13 Oct | Hosting growth path, including AI models | proposed | M | 0 | staged | internal | none | ADR-0004 |
| TD-005 | 14 Oct | Routine panel work to Apps Script | superseded by TD-024 | M | − | ₹0 | internal | none | ADR-0005 |
| TD-006 | 14 Oct | One MMDEP (collector + orchestrator, panel + inbox) | proposed | H | + | ₹0 | internal | none | ADR-0006 |
| TD-007 | 17 Oct | Design, Code and Test harnesses; Gemini as first real model | accepted in practice | H | + | Gemini paid, small | internal | none | ADR-0007 |
| TD-008 | 17 Oct | Repo hand-offs, code preflight, routing blocks, segregation | accepted in practice | H | + | ₹0 | internal / restricted | none | ADR-0008 |
| TD-009 | 17 Oct | Data classes incl. indicative; open work packages for free agents |
proposed (DCL-1) | H | + | ₹0 | all four | check before build (gig workers) | ADR-0009 |
| TD-010 | 18 Oct | Small local models (1.5–7B) and triggers | accepted | M | 0 | ₹0 | client-capable locally | none | ADR-0010 |
| TD-011 | 18 Oct | GitLab compute minutes and the laptop runner | accepted | M | 0 | free tier | internal | none | ADR-0011 |
| TD-012 | 19 Oct | Three flows (P, A, T); merge by risk | accepted | H | + | ₹0 | internal | none | ADR-0012 |
| TD-013 | 19 Oct | API in two lanes (production high risk, staging low risk) | reopened 24 Oct (TD-033) | H | 0 | one more agent | internal | none | ADR-0013 |
| TD-014 | 20 Oct | Knowledge recovery from chats; memory in the repo (rule §21) | accepted | H | + | cents per run | internal (redacted) | none | ADR-0014 |
| TD-015 | 20 Oct | Worktrees, Fabric, Aider, tool list, routing by data class | proposed | H | + | ₹0 | all | none | ADR-0015 |
| TD-016 | 20 Oct | C4-as-code, MADR, rules/skills; two delivery workflows | accepted (ARCH-1, 22 Oct; glimpse before rollout) | H | + | ₹0 | internal | none | ADR-0016 |
| TD-017 | 20 Oct | Program-level controls: MMDEP as hub | proposed (PRG-1) | H | + | ₹0 | internal | none | ADR-0017 |
| TD-018 | 21 Oct | LiteLLM model pool, server sizing, harness guardrails | proposed (POOL-1, SRV-1) | H | + | server ~₹2–3k/month | internal | none | ADR-0018 |
Recent decisions (21–24 Oct), weighed on the five parameters¶
| TD | Date | Decision | Status | V | S | C | D | L | Source |
|---|---|---|---|---|---|---|---|---|---|
| TD-019 | 21 Oct | Roadmap v4: sprints valued by leads (₹10), impressions (₹0.10), visitor-minutes (₹0.10), renewal points (₹10,000 per point) | proposed | H: ties every sprint to revenue | + (one measure) | ₹0; needs analytics | public + client totals only | none | plans/roadmap-v4 |
| TD-020 | 22 Oct | n8n only for business flows (renewals, leads), on the server from S3; not for the code harness | proposed (N8N-1) | H: revenue flows | + for business, − if used for code | ₹0 licence; 1–2 GB on server | client data stays on our server | renewal messages: DLT/WhatsApp templates; check before build | review-22-Oct row 12 |
| TD-021 | 22 Oct | No second CMS (Strapi) until GAP-0 confirms our stack | accepted | M | + (one CMS) | ₹0 | public | none | review row 4 |
| TD-022 | 22 Oct | MWMC: Lighthouse CI and our own crawler for SEO, speed, dead ends; no paid SEO tools | accepted | H (R1) | + | ₹0 | public | none | review rows 1, 2, 5, 9, 21 |
| TD-023 | 22 Oct | Analytics: GA4 + Search Console now, Umami medium term, PostHog long term | proposed | H (measures R1) | 0 | ₹0 now | public, pseudonymous visitors | cookie consent on the site: check before build | review row 7; horizons §C |
| TD-024 | 22 Oct | Agents talk to MMDEP directly: GitHub for-atul inbox now, MMDEP hub on the server later; the claude.ai panel retires after 2 weeks |
accepted (AGT-1) | H | + (no relay) | ₹0 | internal | none | plans/direct-agents §A |
| TD-025 | 22 Oct | Design harness: Claude writes prompt queues; ChatGPT runs a queue per PROCEED; the code harness acts after each step | accepted in principle (24 Oct) | H | + | ₹0 | internal | none | plans/direct-agents §B; sprint-2 pack |
| TD-026 | 22 Oct | Docs site on Cloudflare Pages behind Cloudflare Access | accepted (DOCS-1) | M | + | ₹0 (free plan) | internal docs behind login | none | review §5; PR #132 |
| TD-027 | 22/24 Oct | Knowledge extraction: redacted, paid Gemini; personal chats excluded; runs by itself as a standing job | accepted | H | + | cents per run | internal (redacted), personal excluded | none | PRs #130, #149 |
| TD-028 | 24 Oct | OpenRouter: one-time US$10 credit lifts free models from 50 to 1,000 requests a day; paid models still off | accepted (Atul loaded it) | H (harness volume) | 0 | US$10 once (~₹900) | internal through ZDR providers only | none | horizons §C |
| TD-029 | 24 Oct | Model routing by role: each role has a default model and a next model. Limits are tracked per model (requests per minute and per day, Gemini quotas are per model), and a model is skipped for the day once its limit is reached | accepted (Atul) | H | + | ₹0; uses free and cheap quotas better | per data class (TD-015) | none | backlog B42 |
| TD-030 | 24 Oct | Every proposal weighed on V/S/C/D/L; legal opinion per use case before building | accepted (Atul) | H | 0 (small form per decision) | ₹0 | — | — | this register §1 |
| TD-031 | 24 Oct | Call-recording analysis (transcribe, extract objections and outcomes) stays in the design. Recordings come with consent of the caller or the receiver, stay inside our systems, and are never published. Legal check before build | proposed (design element) | H (R2) | 0 | ₹0 on CPU now; GPU later | client: local machines only | check before build | review row 11; horizons §C |
| TD-032 | 24 Oct | Sonnet (Claude Code) works API/MM-Cron and MWMC in sprint 2, alongside the harness | accepted (Atul) | H | + | within Claude subscription | internal; staging data only | none | plans/sprint-2-design-harness |
| TD-033 | 24 Oct | Resume the older ChatGPT API agent with a revised scope: staging lane (lane S) and MM-Cron data work. The current API agent keeps production (lane P) | accepted (Atul); reopens TD-013 | H (doubles API output) | 0 (one more agent, clear lanes) | ₹0 (existing account) | internal; staging only | none | API-2 in Actions |
| TD-034 | 24 Oct | MMDEP Assistant becomes a ChatGPT project and a coding backup (low-risk GitHub issues, attended) | accepted (Atul) | M | + | ₹0 | internal | none | ASSIST-1; review row 27 |
| TD-035 | 22 Oct | Heavy tools in three horizons: small models and CPU now; one GPU desktop medium term; scale by value later | proposed | M–H | 0 | ₹1–2.3 lakh one-time (medium) | client-capable locally | none | plans/direct-agents §C |
New proposals from Atul's items of 24 Oct (evaluated; awaiting Atul)¶
| TD | Proposal | V | S | C | D | L | Recommendation |
|---|---|---|---|---|---|---|---|
| TD-036 | Skill layer (Agent Skills open specification: one folder per skill with SKILL.md, scripts, references, loaded only when relevant) | H: less prompt drift, smaller contexts for small models. We already have skills (B27); this standardises them | + (one format for all agents) | ₹0 | internal; a skill folder must not embed secrets or client data | none | Adopt the format for our existing skills (docs/agents/skills/ → skills/<name>/SKILL.md + scripts + references), loaded by the harness and Aider by matching when_to_use. Without n8n: the harness selects skills (B44) |
| TD-037 | Codex CLI / desktop with the ChatGPT plan's limited credits | M: one more coding engine on our repos (codex exec, non-interactive) for small daily jobs. It works on repositories, not on ChatGPT project chats: it can't "drive" those chats, and driving them through browser automation would be fragile and against the product's terms of use |
0 (another engine behind the same routing block) | ₹0 within plan credits | internal (the repo it runs on) | none | Spike in S2: add codex as a harness engine like Aider (B45). Use it for 1–2 low-risk issues a day while credits last, and compare its pass rate with Gemini's |
| TD-038 | ChatGPT scheduler (scheduled tasks; event triggers need ChatGPT Work, not available on Go) | M: could make PROCEED automatic if a scheduled task can read the repo and write back | + if it works | ₹0 on Go; event triggers need an upgraded plan | internal | none | Run the 5-test proof first (execute, connector read, connector write, file write, cross-run persistence). Do the GitHub read/write tests in a test repo (SCHED-1). Upgrade only if a PROCEED-replacement use case passes and the upgrade costs less than the Atul-minutes it saves |
| TD-039 | India Stack and Indian models (Bhashini translation, BharatGen models, Account Aggregator, UPI, ABDM, AIKosh) | Mixed: Bhashini M (regional-language calls and content, R2 later). AA M–H long term (financial data with consent, but needs regulated FIU onboarding). UPI collection L for renewals (premiums go to the insurer). ABDM L for a distributor. BharatGen M later on GPU. AIKosh contributions L | 0 to − (each is a new integration) | mostly ₹0 APIs; AA needs registration costs | client (AA, ABDM, calls): India-region, consent-based | AA and ABDM: regulated, check before build | Keep as long-term design elements. Medium term: try Bhashini with call transcription (TD-031). Long term: AA when the advisory product needs verified financial data. Not in sprints 2–4 |
25 Oct¶
| TD | Date | Decision | Status | V | S | C | D | L | Source |
|---|---|---|---|---|---|---|---|---|---|
| TD-040 | 25 Oct | Allocation: harness and ChatGPT agents first; Sonnet only for critical-path items, escalations and cx 3–4 MMDEP code; Claude for high-risk design; context pack (AGENTS.md, CURRENT.md, ACTIVE.md) in every repo | accepted (Atul) | H | + | saves Claude quota | internal | none | docs/agents/allocation.md |
| TD-041 | 25 Oct | MM-Cron completion by end of S3: Sonnet builds one adapter framework; the harness builds one adapter per AMC (51) from public samples; AMFI scripts finished; writes only through the API | proposed | H (R1 fund pages, PE data) | + (one pattern ×51) | ₹0; free models allowed (public data) | public | AMC site terms of use for automated download: check before build | setup doc §2 |
| TD-042 | 25 Oct | API/MM-Cron design: the ChatGPT agent drafts designs (it has GitLab); Claude reviews and writes the high-risk ones; a separate "API & MM-Cron Design" Claude project when review volume exceeds ~3 sessions a week. Sonnet doesn't do design | proposed | H | + | Claude quota only when needed | internal | none | reply to Atul 25 Oct |
| TD-043 | 25 Oct | Code harness on demand: a GitHub self-hosted runner on the laptop (later the backup machine or server) runs it when an issue is labelled agent:harness or on dispatch; the hourly task stays as fallback | accepted, live 26 Oct (HARN-OD) | H (utilisation) | + | ₹0 | internal; runner restricted to collaborators' issues on a private repo | none | PR #161 |
| TD-044 | 25 Oct | Claude "MMDEP Design" project owns overall, phase and iteration designs for MM-Cron, API and stgapi; it reads GitLab through the read-only gitlab-snapshot job | proposed (DESIGN-1); refines TD-042 | H | + | Claude quota, 2–3 sessions a week | internal (docs and trees only; no secrets copied) | none | claude-design-project-instructions.md |
| TD-045 | 25 Oct | Every AI project's instructions and knowledge files are kept in MMDEP (instructions-relay job; docs/agents/project-files.yaml) | accepted | M | + | ₹0 | internal; strip tokens before saving | none | INSTR-1 |
25 Oct (MMDEP Design: API/MM-Cron overall designs, draft 1)¶
Technical choices made by the design authority (TD-044). Status accepted (design): in force for the designs; Atul may veto within 48 hours (rules §21). Source: docs/design/api-mmcron/.
| TD | Date | Decision | Status | V | S | C | D | L | Source |
|---|---|---|---|---|---|---|---|---|---|
| TD-046 | 25 Oct | MM-Cron runs one pipeline for every job: registry → fetch → raw archive → fingerprint → parse → validate → publish → run record. A format mismatch or failed check stops the job before any write | accepted (design) | H: ends silent breakage (Aug NAV stop) | + (one pattern for 51+ adapters) | ₹0 | public | none | mm-cron/overall.md §3 |
| TD-047 | 25 Oct | Every fetched source file is archived with a sha256 manifest (server disk in phase 1, S3 later if needed), so any record can be replayed from its file | accepted (design) | H: traceability, repair-agent evidence | 0 | disk only (factsheets ~1–3 GB a year, estimate) | public | none | mm-cron/overall.md §3, §6 |
| TD-048 | 25 Oct | Identity: AMFI scheme code for schemes; ISIN mapping table; fund family key for holdings; name matching never automatic (proposed match → review list → confirmed mapping reused); exact index symbols | accepted (design) | H: fixes the X2 clash, PE gate | 0 | ₹0 | public | none | mm-cron/overall.md §5; api/overall.md §5 |
| TD-049 | 25 Oct | API contract = docs/openapi.yaml in the api repo, checked by contract tests on stgapi; additive changes free; breaking changes need a consumer check and Atul's approval, preferably as a new route or /api/v2 |
accepted (design) | H: consumers stop guessing | + | ₹0 | internal | none | api/overall.md §4 |
| TD-050 | 25 Oct | MF data responses carry as_of / last_updated; missing values are returned as missing with a reason, never filled or substituted. Same-key writes with a different value are recorded as corrections (detail in the P2 LLD, Claude reviews) |
accepted (design) | H: honest data for R1 fund pages and PE | 0 | ₹0 | public | none | api/overall.md §5 |
| TD-051 | 25 Oct | stgapi isolation on the shared host: staging DBs and users only, staging-only keys, systemd resource caps (MemoryMax, CPUQuota, TasksMax), restarts only through systemd. No staging write until a read-only check proves stgapi's effective DB configuration (closes OR X1) | accepted (design) | H: protects production | 0 | ₹0 | internal | none | stgapi/overall.md §4–5 |
| TD-052 | 25 Oct | stgapi data: loaded from production public GET routes (no production DB access), then kept current by MM-Cron staging runs; daily route parity on a fixed sample, differences classified, not failed | accepted (design) | H: unblocks PE and WPDev on staging | + | ₹0 | public + internal | none | stgapi/overall.md §4, §6 |
| TD-053 | 25 Oct | The design gate covers LLDs in subfolders (docs/design/**/LLD-*.md), because sprint LLDs for API/MM-Cron live under docs/design/api-mmcron/ |
proposed (small MMDEP change; harness item) | M | 0 | ₹0 | internal | none | session 2026-10-25-design |
25 Oct (MMDEP Design: phase-1 designs and the adapter framework LLD)¶
| TD | Date | Decision | Status | V | S | C | D | L | Source |
|---|---|---|---|---|---|---|---|---|---|
| TD-054 | 25 Oct | Fund details: TER, AUM, scheme master and AMC-reported returns come from AMFI (S5–S8) for all AMCs; AMC factsheets are parsed only for the fields AMFI does not publish (managers, benchmark name, risk ratios, riskometer, exit load, inception if missing) | accepted (design) | H: one authoritative source per field | + (halves the PDF work) | ₹0 | public | none | mm-cron/phase-1.md §2 |
| TD-055 | 25 Oct | stgapi data scope: full catalogue and scheme master; full NAV history only for a shared staging set (~200 schemes, docs/staging-set.yaml in api); daily NAV for all schemes from MM-Cron staging runs |
accepted (design) | M: enough for PE, MWMC, parity | + | ₹0; light load on production | public | none | stgapi/phase-1.md §3 |
| TD-056 | 25 Oct | MM-Cron completion is counted per AMC per document type (portfolio, factsheet), built as format families with per-AMC configuration; portfolios before factsheets; top 15 by AUM first | accepted (design) | H: measurable, value-ordered | + | harness: flash-lite or free | public | AMC terms (for-atul) | mm-cron/phase-1.md §3–4 |
| TD-057 | 25 Oct | One ingest pattern for MM-Cron writes: POST /api/ingest/<type>, X-MM-Key per environment, envelope with run id, source and raw sha256; idempotent, replies accepted/unchanged/corrected/rejected; /save-nav becomes an alias after P2 |
accepted (design); build needs Claude review of the API LLD | H: one client, full acknowledgement chain | + | ₹0 | public | none | api/phase-1.md §4 |
| TD-058 | 25 Oct | Holdings: a new read route on mm_data.mm_portfolio / mm_portfolio_items; the legacy route on mm_product_holdings keeps its contract until consumers move; mm_product_holdings is not implemented |
accepted (design) | H: fixes the reader/writer split (KN) | + | ₹0 | public | none | api/overall.md §3; api/phase-1.md §3F |
| TD-059 | 25 Oct | The adapter framework is built as an MMDEP open work package at owp/mm-crons/ with mm-crons' own layout, then moved into mm-crons in one MR by the API agent |
accepted (design) | M: Sonnet can't reach GitLab today | + (move is a copy) | ₹0 | public | none | LLD-adapter-framework §1 |
| TD-060 | 25 Oct | Common output schema v1: JSON Schema files shared by MM-Cron and the API's ingest routes; NAV, money, % and ratios as decimal strings; money in rupees; fields_missing[] on fund details; adapters pure (no network, DB or clock) |
proposed (high risk: Atul approves the LLD) | H: no precision or unit errors, testable | + | jsonschema, openpyxl |
public | none | LLD-adapter-framework §5 |
27 Oct (MMDEP Design: sprint-2 LLDs for API, stgapi and MM-Cron AMFI jobs)¶
| TD | Date | Decision | Status | V | S | C | D | L | Source |
|---|---|---|---|---|---|---|---|---|---|
| TD-061 | 27 Oct | Every API write route declares one class by decorator: M machine (key), F public form (rate limit and origin check, never a key), U user data (session, own LLD). A guard test fails on any write route without exactly one class | proposed (high risk: Atul approves the LLD) | H: no unclassified write can be added | + | ₹0 | internal | none | api/LLD-write-route-security §1 |
| TD-062 | 27 Oct | Keys: X-MM-Key: <id>.<secret>; the server keeps only SHA-256 hashes in a root-only JSON file per environment; env and scope checked; two active keys per consumer for rotation; modes off/log/enforce per environment; enforce after 7 days with zero would-deny and zero legacy calls |
proposed (high risk) | H | + (stdlib only) | ₹0 | secrets on the server and in CI secrets only | none | api/LLD-write-route-security §2–5 |
| TD-063 | 27 Oct | NAV duplicates classified D1 same value (keep lowest id), D2 different values (the source decides: AMFI for schemes, NSE for indices; correction recorded), D3 invalid row (delete); gaps reported, filled only from the source | proposed (high risk) | H | + | ₹0 | public | none | api/LLD-nav-integrity stage A |
| TD-064 | 27 Oct | One NAV write function (persist_nav) behind /save-nav and /api/ingest/nav; unique keys on funds_nav and nifty_index; nav_corrections table; no new writes to funds_nav2; production after a timed rehearsal on a restored full copy |
proposed (high risk) | H | + | one off-hours window | public | none | api/LLD-nav-integrity stages B–C |
| TD-065 | 27 Oct | Ingest destinations: existing tables keep their meaning; new source facts go to new tables (mm_fund_ter, mm_fund_details_src, ingest_runs, ingest_changes); holdings and fund details are versioned snapshots, never edited in place; product creation reproduces cliAum.py until MCRM's ID rule |
proposed (high risk) | H | + | 4 tables | public | none | api/LLD-ingest-routes §2 |
| TD-066 | 27 Oct | stgapi isolation verdict needs configured targets, live connections and grants to agree (ISOLATED only if all are staging DBs); the loader repeats the check before writing; stgapi capped with a systemd drop-in; deploy-staging restarts only via systemctl |
proposed (high risk for the verdict) | H | + | ₹0 | names and grants only, no secret values | none | stgapi/LLD-staging-isolation-and-load §1–3 |
| TD-067 | 27 Oct | Daily NAV from AMFI NAVAll.txt (S4), which also gives early notice of new and renamed schemes; the history portal (S2) for back-fill and gap repair; the scheme master job stays the owner of scheme facts |
accepted (design; medium) | H | + | ₹0 | public | none | mm-cron/LLD-amfi-jobs §1–2 |
| TD-068 | 27 Oct | Version and release practice at our size: exact pins (lock files, image tags), one components baseline per project in the tech-stack register, trunk-based short branches, releases as git tags promoted staging → production with Atul's approval, feature flags as env/config switches. Not now: Argo CD, Harbor, Kubernetes/Helm, Vault (no Kubernetes; upkeep without gain) | accepted (medium) | H | + | ₹0 | none | none | panel note "Version Management" (Atul, 26 Oct) |
| TD-069 | 27 Oct | Code walkthrough and reuse: keep Aider + ruff + docs site/C4; add ESLint/Biome on JS/WordPress repos and a generated code-map page per repo; shared Python code as a git-pinned package, a private package server only when 3+ projects share it. Not now: Bit, Nx/Turborepo, OpenRewrite, Sourcery/CodeSee (code leaves our control, cost) | accepted (low) | M | + | ₹0 | code stays in our repos | none | panel note "Code Walkthrough" (Atul, 26 Oct) |
| TD-070 | 27 Oct | Roadmap published from the repository as a Now/Next/Later page on the docs site, from the same data as sprint plans; a public Notion page later if customers or partners need one. Not now: Productboard, Aha!, ProductPlan, airfocus, JPD (per-user cost, second source of truth) | proposed (Atul: is an external roadmap needed this quarter?) | M | + | ₹0 | internal | none | panel note "Product roadmap publishing tools" |
| TD-071 | 27 Oct | Tech-stack register docs/registers/tech-stack.yaml (per project: languages, frameworks, databases, hosting, exact versions, status adopt/trial/hold/retire), shown on the docs site and linked to C4; drafted by the MMDEP Assistant, checked by each project agent, reviewed by MMDEP-PM by 1 Nov |
accepted (low) | H | + | ₹0 | names and versions only | none | panel note "Technology Stack register" (Atul, 26 Oct) |
| TD-072 | 27 Oct | Five-harness framework (Design, Code, Testing, Research, Work, on one orchestration core) as the programme view, each component with its real status; visualizations are part of every design level, Mermaid in the Markdown by default, C4 from workspace.dsl, images only as labelled concepts; CI adds pytest coverage, bandit and pip-audit (report-only for 2 weeks) | accepted (low) | H | + | ₹0 | no client data or secrets in pictures | AA/DPI and Bhashini: legal check before build | Atul concept image 26 Oct; docs/architecture/harnesses.md; docs/design/visualization-standard.md |