Skip to content

Atul's answers

Newest first. Each entry: date, project, question issue, answer. Agents act on new entries and close the question issue quoting the answer.

Date Project Question Answer
2026-10-20 MCRM #118 is labelled question-atul but is a documentation-only technical choice (MMDEP-PM, rules §14a) You decide: take option A (close G2-ARCH-08 and the XP-01..XP-08 namespace gap once the evidence links on your branch docs/followup-g2-xp-traceability-stacked-v01 verify both), mark it ASSUMED in #118, remove the question-atul label, and report the paths to #113. Atul is asked business questions only.
2026-10-20 WPDev ask-mmdep #30: how to run the authorized CI for MR !301 (MMDEP-PM) Use a merge request pipeline (MR !301 → Pipelines → Run pipeline, or POST /projects/:id/merge_requests/301/pipelines) after confirming the head is still 28fcc3d7; no CI rule changes. If your token is refused, queue a support-test step for Atul. https://github.com/moneymarche-dev/MMDEP/issues/30#issuecomment-6284229668
2026-10-20 MWMC ask-mmdep #40: offline-only harness tests (MMDEP-PM) Use a run-job issue (exact head, exact pytest command, offline) so MMDEP runs only those tests; don't rely on the manual browser job. A CI-rule change goes in a separate medium-risk MR to the integration branch for Atul's sprint review. Your ASSUMED hold is correct. https://github.com/moneymarche-dev/MMDEP/issues/40#issuecomment-6284229825
2026-10-20 PE Run-job #376 done (exit 0, PASS) at head 700f65a6 (workbook inspection) Pinned workbook SHA-256 verified (ebe1caa5…a322), CI #559 green on the exact head, heartbeat ACTIVE. 8 sheets, none missing, 0 formula/error tokens; Review chart reads Chart Data!B2:B915 (914 observations). Note: the inspector's "starting value"/"ending value" label search misses "Starting/Ending portfolio value" (labels are present). Review the CSV exports and visually inspect before accepting #309/#310. Outputs and provenance: https://github.com/moneymarche-dev/MMDEP/tree/main/docs/relay/data/pe-client-review-inspection-2026-10-18
2026-10-20 All projects New rule §21: write what you say, keep memory in the repository, send questions and decisions to Atul directly (Atul, 10:52 IST; DR-014) From your next PROCEED:
1. Before replying, append the full reply plus your steps and commands to docs/sessions/YYYY-MM-DD.md and commit it.
2. Keep docs/knowledge/CURRENT.md, DECISIONS.md and OPEN-QUESTIONS.md current. Create them now from what you know, and say what you couldn't recover.
3. Commit every artefact you make in the same session. MCRM: the category and product-line sample JSONs you made earlier were never saved. Recreate and commit them.
4. Business questions go in question-atul issues; significant decisions you took go in decision-log issues (Atul may veto within 48 hours).

Rules: https://github.com/moneymarche-dev/MMDEP/blob/main/docs/agents/mmdep-agent-rules.md §21. Plan: https://github.com/moneymarche-dev/MMDEP/blob/main/docs/decisions/DR-014-knowledge-recovery-and-memory.md | | 2026-10-19 | PE | #330 answered: C, skip Conservative history tests in Phase 1 (Atul, panel 20:03 IST) | Keep Conservative replay NOT_RUN for Phase 1, record the decision in #330 and close it. Aggressive and Moderate continue. | | 2026-10-19 | API/MM-Cron, MWMC, WPDev | Atul: why are CI-waiting MRs still open? The laptop runner works now (panel, 20:13–20:16 IST) | Next PROCEED, for each MR listed: - API: the 8 MRs needing CI. - MM-Cron: 4 MRs needing CI, plus 1 security record. - MMCLONE sandbox (MWMC): about 10 test MRs, plus 4 that need a job on the MMCLONE server. - Production site (WPDev): 6 docs MRs, 1 needing Atul's approval.

Do: 1. Start or re-run the pipeline on the laptop runner. 2. Green and low risk: merge it (DR-012). 3. Red: fix it or close it with a reason. 4. Superseded or stale: close it. 5. High risk: one line in question-atul.

Report the before and after counts in your reply and in your sprint design file. | | 2026-10-19 | API/MM-Cron | AMFI factsheet links: browse from the cloud and post the exact paths (Atul, 13:49 IST) | Atul can't reach amfiindia.com from his current location. Use ChatGPT cloud browsing on https://www.amfiindia.com/online-center/download-factsheets. It lists 51 AMCs, and the links open only on click. Post AMC, URL, type, file pattern, history as a comment on https://github.com/moneymarche-dev/MMDEP/issues/64 and commit the CSV in mm-crons. Full instructions are in the issue. Priority: before any factsheet-parser planning. | | 2026-10-19 | PE | Atul's answers on #329 and #375, and direction for sprint 1 (panel, 12:23–12:35 IST) | #329, portfolio evaluation: judge each portfolio on three comparisons: 1. stated objectives vs actual; 2. against benchmarks; 3. against peers. For the model portfolios, we define the standard objectives, benchmarks and peers ourselves, drafted carefully and verified by a test agent. For other portfolios, users adjust the model portfolio's criteria.

#375 and overall direction: - Representation should work the way indices do: a handful of holdings represents the market, with weights assigned and adjusted dynamically so alpha, beta and the other measures track true market behaviour. Equal or static weights are not enough. - PE is stuck on the 25-direct-fund universe. Look forward, expand the horizon to the next stages, and make your own assumptions (ASSUMED) and proceed this sprint. - Deliver a full view: the design for the coming phases and the missing areas. - Check that the specifications Atul gave for the next phases are recorded in the repository, including the EDHEC course modules and the other product-portfolio presentations. List anything not found as a gap. - Fix data quality first, using what you learned from the API implementation and WPDev's API study. Earlier problems came from incomplete API knowledge and MM-Cron gaps when the database was built. Show what you have implemented since.

#330: Atul asked for an explanation with examples; MMDEP-PM is explaining it to him. Keep Conservative replay as it is meanwhile. | | 2026-10-19 | WPDev (and MWMC for sandbox #27) | Atul: WPDev decides website #123 and sandbox #27 (panel, 12:37 IST) | Both are technical choices for WPDev to make. - #123 (unknown deep mutual-fund addresses): decide, record the choice as ASSUMED in the issue, and implement it. Default suggestion: keep known old addresses and return Not Found for unknown deep paths. - Sandbox #27 (route checker's page-list source): WPDev gives MWMC the source from its API study. No logins, forms or production writes.

Close both with your decision. | | 2026-10-19 | API/MM-Cron | Data source registry: AMFI factsheet index found; verify it (Atul, 12:40 IST) | Atul: no data planning is fruitful without a correct source registry. - Registry: MMDEP-PM seeded https://github.com/moneymarche-dev/MMDEP/blob/main/docs/registers/data-sources.md from your MF-DATA-MAP plus AMFI's factsheet index, https://www.amfiindia.com/online-center/download-factsheets (lists every AMC; not in MF-DATA-MAP). - Sprint 1, high priority: 1. Verify, for every AMC, where its factsheet link leads (direct PDF or AMC page), and how files are named. 2. Commit the list as amfi-factsheet-links-YYYY-MM.csv. 3. Fill in every UNKNOWN in the registry. - From now on: add each new source as a row before planning work on it. You own the registry. | | 2026-10-19 | All projects | Risk class in every routing block from sprint 2; communication only through repositories (Atul, 11:53 IST) | Rules §19 and §20. Sprint 2 preflight must add risk: low/medium/high (DR-012 §5) to every item; low-risk items then merge themselves on green CI. Never leave anything another agent needs only in a chat. | | 2026-10-19 | API/MM-Cron | API becomes the first project on all three flows, in two lanes (proposal DR-013, pending API-1) | You become Lane P (production, high risk): production deploys with Atul, write-route security, production data fixes, MM-Cron production jobs, cross-project contracts. A second agent, Lane S (staging, low risk), will take staging promotion, staging data load, smoke tests, docs and MR clean-up, and merges itself on green CI. Until Lane S starts, carry on as now. From today, label every GitLab issue you create lane:prod or lane:staging. Plan: https://github.com/moneymarche-dev/MMDEP/blob/main/docs/decisions/DR-013-api-two-lanes.md | | 2026-10-19 | API/MM-Cron | Secure the API write routes, production and staging (Atul, 10:28 IST; sprint 1 plan, sprint 2 rollout) | Plan, then implement, authentication for every write route on api.moneymarche.com and stgapi.moneymarche.com. Scope: POST /save-nav, POST /jobs/upload, POST/PUT /api/home-page-categories, and every other POST/PUT/DELETE in src/routes.py. - Machine writers (MM-Cron, the staging loader): a per-consumer key in a header, compared in constant time; separate keys for staging and production. - Client-data routes (customer, KYC, bank details, nominee, family, address, income, portfolio): need user-session auth, so plan them separately.

Rollout without breaking anyone: 1. Inventory: every route × every consumer (you started this in the route/DB consumer matrix, branch docs/api-39-route-db-consumer-matrix). 2. Log-only mode: accept and log calls without a key, per route and caller. 3. Consumers switch: each project adds its key (see the next rows). 4. Enforce, staging first, then production with Atul's approval. 5. Rotation and audit log.

Rules: - Keys live only in server env files and CI secret variables; never in a repo, chat or issue. - A person creates and installs them. - Use the existing API_KEY config as the starting point if it fits.

Deliver: - an LLD in sprint 1 week 2; - staging enforced in sprint 2; - production enforced once every consumer is switched.

Sprint 3: extend the same scheme to read routes (rate limits and keys for non-public reads; public catalogue and NAV reads stay open, with caching). | | 2026-10-19 | MWMC, WPDev, MCRM, PE, MM-Cron | Notice: the API write routes will require a key (Atul, 10:28 IST) | The API agent is securing every API write route (/save-nav, /jobs/upload, /api/home-page-categories, quote, enquiry, booking, user and customer routes) on production and staging. Each project, before the end of sprint 1: 1. List every API write call your code makes: route, method, file, and whether it runs on a server or in a browser. 2. Put the list in your sprint-1 design file, and open an ask-api issue in your repository if anything is unclear.

Then: - When the API agent publishes the header format, add the key from your server env or CI secret (never in code, never in browser JavaScript). - Browser-side writes (website forms) need a server-side relay or a user session. Say which in your list. - Sprint 3: the same for authenticated read routes. | | 2026-10-19 | API/MM-Cron | Staging data load assigned to the API agent (Atul, 00:30 IST) | Load cleansed production data into stgapi. Scope (route check on api-phase1-development): - Scheme NAV: read the production GET routes, de-duplicate dates and flag gaps (your sprint-1 priority 1 rules), then POST to stgapi /save-nav. - AUM/TER/NFO: check whether /jobs/upload can carry them. - Catalogue (products, owners, categories, fund details) and index NAV: there are no save routes (category POST/PUT are commented out). Use a loader that reads production's public GET routes and writes mm_api_staging/mm_nav_staging with the staging credentials (/opt/bitnami/api/staging-secrets/db.env). No production DB access.

Rules: - Start from your docs/api-40-staging-data-population-contract-2026-10-10 branch. - Prove /save-nav on staging with one scheme first. - Dry-run mode; idempotent (safe to rerun). - Never write production or mm_data. - Data class is public. - Atul runs it over ssh moneymarche-aws, or as a laptop-runner job, so give him exact steps (no nested double quotes in PowerShell). - Report row counts per table and the cleansing decisions taken (ASSUMED where not decided).

Order: after the stgapi promotion MR (previous row), or in parallel if independent. | | 2026-10-19 | API/MM-Cron | stgapi restored; follow-ups (MMDEP-PM, 00:30 IST) | stgapi is back (all smoke routes 200) under systemd mm-stgapi.service, running Release-C 825127e0 from api-phase1-development; details at https://github.com/moneymarche-dev/MMDEP/blob/main/docs/runbooks/stgapi-restore.md . API agent tasks: (1) promote the current api-phase1-development into api-phase1-staging-release with an MR (brings !147 resolver fix and the !132/!162 security fixes); Atul then starts deploy-staging on the laptop runner; (2) change deploy-staging to restart with sudo systemctl restart mm-stgapi (narrow sudoers rule) instead of starting python itself; (3) stale MySQL connection fix (pool_pre_ping/pool_recycle; NAV engine uses MYSQL_UNIX_SOCKET instead of MYSQL_NAV_UNIX_SOCKET); (4) record that /opt/bitnami/api/api (2024 copy) must never be started on 5001. | | 2026-10-19 | API/MM-Cron | stgapi restore (Atul, 19 Oct 00:00) | MMDEP-PM extracted the staging layout from the TEA chat: app /opt/bitnami/api/api_stg_release/app, python3 app.py on 5001 with no process manager, env /opt/bitnami/api/staging-secrets/db.env, DBs mm_api_staging/mm_nav_staging, Release-B 614b0bef. Runbook with a systemd unit, smoke tests and rollback: https://github.com/moneymarche-dev/MMDEP/blob/main/docs/runbooks/stgapi-restore.md . Staging is Atul's (built by the earlier API agent, installed by TEA through Atul's SSH), not Ajay's; Atul runs the read-only check first. API agent: then change CI deploy-staging to restart through systemd, and fix the stale-connection defect (pool_pre_ping/pool_recycle, NAV socket). | | 2026-10-18 | API/MM-Cron | Ajay's answers to the 15 Oct to-do list (Google Doc "MMDEP — Questions for Ajay", edited 18 Oct 15:45 IST) | (1) Certificate auto-renewal (A2): the failing cron is Bitnami's bncert-autorenew line, which runs lego ... --domains=www.moneymarche.com renew with only the www domain, while the live certificate covers 7 names (www, api, app, staging, crm, mautic, stgapi) and was renewed by /home/bitnami/scripts/ssl-scripts/renewssl.sh. Ajay suggests switching the cron to that script. Write a support-release runbook: replace the bncert line with a root crontab entry (no sudo inside) that runs renewssl.sh daily with a log, plus a check that prints the expiry date; Ajay applies it. Deadline 10 Dec (expiry 13 Jan 2027). (2) stgapi 503 (C1): the staging API is a Python service, /opt/bitnami/api/api/app.py on port 5001, not running; it may have other dependencies. Write a runbook with a systemd unit (restart on failure, start at boot) and a health check; a person applies it over SSH. (3) Staging data (C2): Ajay prefers copying production API data into the staging database (dump and load). Write the dump/load script for the API tables only; mm_data is shared by staging and production, so staging must never write to mm_data (unchanged rule). (4) Read-only production user (C3): not created yet; write the CREATE USER ... GRANT SELECT script (password set by the person at the prompt, never in the repo); a person runs it. (5) Adminer (C4): Ajay needs it but asks for a secure alternative. Recommend binding Adminer to localhost and using it through an SSH tunnel (ssh -L), so it is no longer reachable from the internet; fallback: Apache basic auth plus an IP allow-list. Put both in one runbook. (6) mm-crons (C5): the live crontab matches mm-crons-v2.zip; credentials there moved to prod.conf / prod.json. Go ahead with the MR that retires everything outside the v2 set. (7) AWS (B3, B4): Lightsail instance WordPress in Mumbai; S3 buckets mmkyc (KYC document uploads from the React/Sakai app) and mmlambdalayers (Lambda layers); MM-Cron Lambda is mm-crons/lambda/navdata/handler.py, method handler. mmkyc holds client KYC documents (client data class): raise a security item asking Ajay or Atul to confirm in the console that Block Public Access is on and that the bucket is encrypted; names and settings only, never contents. CloudWatch log groups still unknown. (8) Others: snapshot automation (B1) still to do; October snapshot taken by hand; dev.moneymarche.com DNS removal stays with Atul at the DNS provider (panel DNS-2); NIFTY 50 data is current to 16 Oct, so the 13 Oct fix holds; SuiteCRM secret: Ajay agrees to move it to config (D1). | | 2026-10-15 | PE | run-jobs #335 and #336 | #335 done (exit 0): point-in-time replay preflight COMPLETE for Aggressive and Moderate, weekly (204/204 intervals) and monthly (52/52), no blockers; outputs in MMDEP docs/relay/data/pe-preflight-phase1-objective-replay-2026-10-15/ (+ .md). Commit them as evidence and close #335 quoting this line. #336 failed (exit 1): SnapshotNotCachedError — the workbook script cannot find the schemes catalogue in the extracted cache ZIP layout; fix the mapping, push a head with green CI, update #336 and MMDEP will rerun. Log: docs/relay/data/pe-client-review-workbook-2026-10-15-FAILED.log. | | 2026-10-15 | API/MM-Cron | Ajay on mm-crons (Q-14.1) and TLS (Q-14.3) | (1) The live MM-Cron scripts are the set Ajay shared as mm-crons-v2.zip; all other files in mm-crons can be retired and kept for reference. Plan an MR that marks the rest as retired (move to retired/ or document), after comparing with the v2 set (MMDEP will put the v2 file list in docs/relay/data). (2) The files may contain credentials: include them in the secret scan and clean-up. (3) dbbackup/ holds reference backup scripts, one per database. (4) The certificate was renewed manually (new expiry 13 Jan 2027) with /home/bitnami/scripts/ssl-scripts/renewssl.sh; the renewal cron did not run, probably a sudo issue: add a support-release item to fix auto-renewal before December. SuiteCRM integration is now lowest priority (Atul, 15 Oct); the SuiteCRM secret rotation stays. | | 2026-10-14 | PE | Objective-selection report executed for you | You have no execution environment, so MMDEP ran your committed renderer (PR #321 @ e324f61, unmodified) against the committed evidence and manifest: exit 0, 210-line report, your report tests 7 passed. Report with provenance header: MMDEP docs/relay/data/pe-objective-selection-report-2026-10-14.md. Commit it to #321 as the code-generated artifact (keep the header). Data point to act on: the Aggressive profile holds schemes 147662 and 120594, the two series whose NAV stops on 2026-05-22 in the cache (run-job #324) — record this as a limitation on Aggressive and include it in the ask-api freshness requirement (#326). For future runs, open a run-job issue; MMDEP executes it. | | 2026-10-14 | PE | run-job #324 (NAV-cache analyser) done | Exit 0, ZIP integrity PASS, analysis COMPLETE: 25/25 series, 914 exact common dates (2021-07-01 to 2026-05-22), 205 weekly and 53 monthly formation dates, no index files (NOT_AVAILABLE_IN_INPUT_ARCHIVE). Common window ends 2026-05-22 because schemes 120594 and 147662 stop there (others run to 2026-08-19): raise as an ask-api/MM-Cron data gap. Outputs: MMDEP docs/relay/data/pe-analyze-phase1-nav-cache-2026-10-14.md and folder. Commit the outputs as PE evidence if you need them in your repo, and close #324 quoting this line. | | 2026-10-14 | PE | PE joins MMDEP (Atul, 17:18) | New project instructions: MMDEP docs/agents/projects/pe-project-instructions.md. Key changes: TEA retired, MMDEP owns promotion; PE does not gate other projects' merges (raise ask-api requirements instead); nobody waits; scope cuts need Atul; scripts that need the laptop or local data go through a run-job issue (script on a branch under tools/jobs/), MMDEP runs them and returns output here; at most 5 open PRs; plan first (docs/plan/PE-PLAN-2026-10.md, milestones P1–P3). | | 2026-10-14 | MWMC | website-tests folder (PF-2, Atul 13:19) | C:\Projects\website-tests (not under git) holds MMCLONE tests you created earlier: tests/http/mmclone_seo_baseline.py, tests/selenium/mmclone_smoke.py and their JSON outputs, plus reports, screenshots and agent prompts. The sandbox repo has two segments: MMCLONE differential code and test code. Decision: these belong in the test segment of the sandbox. Compare them with the sandbox's existing tests (tests/homepage_compare.py, harness/browser.py, tests/browser/smoke.py), keep what is unique, and add it through one small MR (no screenshots or reports in git; outputs as CI artifacts). Atul or Claude will supply the files if you cannot read the laptop folder: raise an ask-mmdep issue. | | 2026-10-14 | API/MM-Cron | Secrets in mm-crons scripts (PF-1, Atul 13:16) | An audit of folder names in moneymarche/mm-crons found tracked scripts, not dumps: dbbackup/, sql/, insurance/, bajaj allianz/, suitecrm/. Several files match secret-like words (suitecrm/SuiteCRM.py, suitecrm/get_entry_list*.php, insurance/load-*.py, bajaj allianz/readdata.py); values were not read. Run a secret scan on mm-crons (all branches and history), list findings by file and line without values, move any real secret to environment settings, and add them to the security fast-lane rotation list. Ajay is asked (Google Doc Q-14.1) which of these folders still run as cron jobs. | | 2026-10-14 | MWMC | Route crawler inputs and daily route health (Atul, 11:46) | (1) The on-request crawler takes filters so a run can be short: START_PATH (default /), MAX_DEPTH (default unlimited), optional INCLUDE/EXCLUDE path patterns and MAX_PAGES; pipeline variables, recorded in the output. A filtered run only adds and updates routes under its start path; it never marks routes outside it as gone. (2) Add a small daily scheduled job, route health: re-check every route already in the inventory (no discovery), record status and redirect target, and report routes giving 404, 5xx or unexpected redirects as a short artifact and one rolling issue (route-health), updated each day, closed items ticked. Same politeness: at most 1 request per second, identifying user agent, GET/HEAD only, runs 05:00–07:00 IST on the laptop runner. Both are CI changes: one MR each, Atul merges. | | 2026-10-14 | MWMC | Route crawler schedule (Atul, 11:33) | Correction: the route crawler is not nightly. Make it a manual pipeline job (run on request) on the laptop runner, run after every major release and whenever Atul or an agent asks. Same rules otherwise: read-only, at most 1 request per second, identifying user agent, no forms or logins, adds new routes and marks gone ones, dated artifact plus diff. | | 2026-10-14 | API/MM-Cron | Milestones recalibrated (Atul, 11:30) | Your order: (1) A1 release 1 (security batch) to production; (2) A3a pulled forward: /category returns the stored status and show-in-menu flags, with a test (small fix; unlocks MCRM's category tree and MWMC's category sitemap); (3) A2 data trust: write the staging database load (copy from the production API database), housekeeping, cleansing and missing-record scripts, staging-only writes; list now, as a support-release issue, every DB access step a person must do, so A2 does not wait later. Plan: MMDEP docs/plans/programme-milestones-2026-10.md §2–3. | | 2026-10-14 | MWMC | Route inventory as a recurring job (Atul, 10:57) | The route inventory serves two purposes: test coverage and SEO. (1) Close #20's current pass with the public record (MMDEP docs/relay/data/mwmc-public-routes-2026-10-14.md) plus your merged inventory. (2) Find your earlier Selenium route crawler (it found 700+ routes before GitLab minutes ran out; check your branches and old pipelines) and turn it into a scheduled pipeline on the laptop runner (tags laptop,docker): crawl production read-only to the last leg, record each URL's status, canonical and source page, and add newly found routes to the inventory each run (never delete; mark gone routes). Polite limits: at most 1 request per second, identifying user agent, no forms or logins, run between 01:00 and 06:00 IST. Output: a dated JSON/CSV artifact plus a short diff (new, gone, canonical changes). One MR for the job; Atul merges it because it is CI. Until then continue the M2 SEO fixes. | | 2026-10-14 | MWMC | Route discovery is finished; move to M2 (Atul, 10:45) | Stop route discovery. Live sitemap, robots, status and canonical data are now in MMDEP docs/relay/data/mwmc-public-routes-2026-10-14.md (107 sitemap pages, robots blocks /category/). Use it and close the discovery part of #20. M2 SEO fixes, in order: (1) breadcrumb fix #29; (2) product and AMC pages canonicalise to the generic /product and /product-owner with generic titles — make canonical and title page-specific; (3) add product/AMC/category sitemaps and review the /category/ disallow; (4) drop template leftovers from the sitemap. One issue and one small MR per fix, tested on MMCLONE, production only through a support-release issue. !42 (CI split) is with Atul to merge; while it waits, work on (2)–(4). Nobody waits. | | 2026-10-14 | MWMC | MW-U: unblock the loop (Atul, 10:00) | Approved and done in an attended PROCEED: route inventory from public sources merged (!40, !41, !44; sitemap and /category still UNKNOWN); sandbox MRs cleaned to five open (!14, !19, !42, !43, !45), !24 split; CI allowed on the laptop runner and Top 5 corrected; M1 done except SSL #26 (Atul); M2 started with issue #29 (breadcrumb fix, tests, rollback). Standing rule: Nobody waits; #27's export confirms later and blocks nothing. Next: !42 review, offline harness under support-test #30. | | 2026-10-14 | API/MM-Cron | SEC-1: SQL-injection fixes !162 and !132 (Atul, 06:39) | Approved as recommended. Merge !162 into api-phase1-development now. For !132, first list the sort keys the website actually sends (webapp-sakai product.ts and WPDev); if all are in the new fixed list, merge it; if not, add them with a test, then merge. Report both on support-test #44. Production goes in the weekly security batch: prepare it as release 1 (MRs, test evidence, rollback, staging check) for Atul's approval. | | 2026-10-14 | API/MM-Cron, MWMC, MCRM | Scheduled-run hours (Atul, 06:33) | Scheduled runs now work 07:00 to 23:00 IST (was 09:00 to 21:00); rules §7 updated. Use the extra hours to finish preparation so a PROCEED can post it straight away. Priority stays: first meaningful release, through the agreed process. | | 2026-10-14 | MCRM | Questions #107 to #112 (owner record §14) | #107: option B (Catalogue Manager sets ID rules; API database stays store and writer). #108: option A (regulator for UIN, provider for wording, API owner publishes). #109: option B (WordPress admin stays the edit screen for now; in future categories and products move to the SuiteCRM catalogue). #110: option B (MCRM owns field meaning, API agent owns the running API, breaking changes need a consumer check and Atul's approval); everything except mutual funds is MCRM's domain. #111: no migration in the current phase; first move direct database calls to the API and make the API expose everything the database reads give today. #112: option C (decide after WP1). Close each issue quoting the answer. | | 2026-10-13 | MWMC | Plan source, owner notes, merge permission | (1) Plan source: GitLab moneymarche/webapp-sakai, branch plan/mwmc-2026-10 (MR !7, merged), file docs/plan/MWMC-PLAN-2026-10.md; copy it unchanged into the sandbox through a documentation MR. (2) Owner notes and plan MRs are exempt from the open-MR limit (rules §4); open the MR and merge it. (3) Your GitLab identity got 401 on merge and 403 on push in the sandbox: Atul merges !38 and fixes the permission; until then leave merges for him and say so in one line. | | 2026-10-13 | MWMC | CI on the laptop runner (Atul, 22:42) | The laptop runner now serves money-marche-testing (sandbox) as well as moneymarche (webapp-sakai). Any earlier "no CI / quota exhausted" rule is withdrawn for these groups, on condition that every job carries the tags laptop and docker (never GitLab's shared runners). In the sandbox: one MR that tags all jobs, removes any CI-blocking gate, runs fast tests automatically on merge requests, skips documentation-only changes, and keeps browser-heavy suites manual or nightly; merge it after its own pipeline passes (Atul approved). Server changes on MMCLONE stay support-release steps for a person; CI holds no server credentials. Report the pipeline link. | | 2026-10-13 | API/MM-Cron | CI quota restriction lifted (Atul, 22:15) | The "do not run GitLab CI, CPU quota exhausted" rule (handover !166 §1/§17, issue #44, the CI global operating-mode docs and any test or flag enforcing it) is withdrawn. It existed because GitLab's shared runners had no minutes left. A group runner on Atul's laptop (tags laptop, docker) is online since 13 Oct 19:01; jobs on a group runner use no GitLab compute minutes. New rule: CI may run, but every job must carry the tags laptop and docker so it never lands on GitLab's shared runners; deploy and release jobs stay manual. Disable or update the test/flag that blocks CI as part of the CI MR. Proceed with the CI MRs and the #44 security tests now. | | 2026-10-13 | API/MM-Cron | CI mode (Atul, 21:38) | Review the CI setup in API and MM-Cron (a global flag switches manual/auto). Switch test jobs to automatic on merge requests and pushes, on the laptop runner (tags laptop, docker), skipped for documentation-only changes; deploy and release jobs stay manual. One small MR per repo; Atul approved this change, so merge it after its own pipeline passes. Then prove it: push a commit to the security-fix MR (API !132 or !162) and report the pipeline link and result on support-test #44. | | 2026-10-13 | API/MM-Cron | Ajay's writer table and crontab (owner record §13) | Update the plan's writer inventory and MF-DATA-MAP from §13 (exact scripts and schedules). Add work items: (1) Adminer is internet-facing: propose restricting it (IP allow-list or extra login) as a support-release runbook; (2) create a read-only database user by script, run by a person over SSH; (3) remove the unused Mongo code (Ajay confirmed); (4) SuiteCRM integration needs validating before the secret rotation; (5) cliAum.py -m scheme runs by hand monthly: propose scheduling it; (6) NIFTY 50 should resume after Ajay's 13 Oct fix: the collector will confirm. | | 2026-10-13 | MMDEP (relay R5) | Certificates | The only renewal cron on Lightsail covers www.moneymarche.com. Check whether moneymarche.com, api, stgapi, app, crm, dev, mautic and staging are on the same certificate; the collector's weekly check shows each host's expiry. | | 2026-10-13 | MCRM, API/MM-Cron, MWMC | Writers and sources (owner record §12) | Category tree and product custom content are written by the production website's admin panel directly to the database (it auto-creates a page per category, data from the API, with editor content on save); next phase moves these writes to the API. MF products: MM-Cron discovers new schemes from AMFI NAV data and fills details from AMFI sites. Insurance: IRDAI first, then insurer sites. MCRM: include admin-panel editing and category pages in the tree proposal. API: plan the write endpoints the admin panel will need. MWMC: locate the admin panel code and its database writes. | | 2026-10-13 | MCRM | Category tree first (owner record §11) | Propose the category tree before the product work: current production tree (menu code reads status and show-in-menu correctly; "Market Cap Oriented Funds" is an administrative branch, not in the menu) versus the larger staging tree (staging.moneymarche.com, repo money-marche-group/money-marche-website-staging), then the target tree with status, show-in-menu and administrative branches for each node. Make it part of WP1. | | 2026-10-13 | API/MM-Cron | /category flags defect | /category returns status and show-in-menu as 1 for every category, while the database holds real values (the production menu reads them correctly). Add a Phase B/D item: return the stored flags, with a test; coordinate field meaning with MCRM. | | 2026-10-13 | API/MM-Cron | CI for support-test issues | The laptop runner is online for the GitLab group moneymarche (rules §5). Run the pipelines for support-test #44 (API !132, !162) and for API !168 / MM-Cron !81, one at a time, and post the results on the issues. | | 2026-10-13 | MWMC | MMCLONE address | MMCLONE is http://mmclone.arevalifestyle.com (a subdomain inside the Bluehost account of arevalifestyle.com), not mmclone.moneymarche.com. Use this address everywhere; SSL is not set up yet (relay R4). | | 2026-10-13 | MWMC | MMCLONE SSL | MMCLONE works only over http (no valid certificate yet). Post relay R4 from docs/relay/outbox.md as a sandbox issue and plan the fix; server steps go to Atul as a support-release issue. | | 2026-10-13 | MWMC | Is the October plan approved, and where is it? | Approved 13 Oct (MWMC-0). It was merged in webapp-sakai through MR !7 (source branch plan/mwmc-2026-10, file docs/plan/MWMC-PLAN-2026-10.md; check the MR's target branch). Copy it unchanged into the sandbox repo, then continue with the Top 5. | | 2026-10-13 | API/MM-Cron | Credential MRs API !168 and MM-Cron !81 | Good. Next: an inventory of every job and service using /save-nav, the database credentials and SuiteCRM credentials, as a short document; then a support-test issue for running the MRs' tests on the laptop runner once it exists. Ajay reviews the variable names. | | 2026-10-16 | PE | Run-job #336 (client review workbook) at head d15bda77 | FAILED again, exit 1 (ValueError: compare_funds requires at least 1 subject, got 0). Root cause found by MMDEP: the pinned ZIP was created on Windows, so its entry names use backslashes (scheme_nav\118942.parquet, not scheme_nav/118942.parquet). On Linux (MMDEP's runner and GitHub CI) these extract as flat files named scheme_nav\NNNN.parquet at the root, so no NAV is found and 0 funds load. Fix in the extractor: normalise \ to / in every member name before extracting, and reject names containing ... Add a regression test with a backslash-named ZIP member. Keep the ZIP and its hash unchanged. After green CI on the new exact head, update #336 and MMDEP reruns it automatically (rules §14). Log: docs/relay/data/pe-client-review-workbook-2026-10-16-FAILED.log | | 2026-10-16 | PE | Run-job #337 | Not run: the issue itself is on HOLD for the renderer count-reconciliation fix. Update the issue with the new exact head once CI is green, and MMDEP runs it. | | 2026-10-16 | ALL | New rule §14: heartbeat and nobody waits | Read https://github.com/moneymarche-dev/MMDEP/blob/main/docs/agents/mmdep-agent-rules.md §14. Check https://github.com/moneymarche-dev/MMDEP/blob/control/HEARTBEAT.md at every run. Don't wait for Atul on gate-green run-jobs, docs-only or development merges, or reversible questions (take your recommended option, mark it ASSUMED). | | 2026-10-17 | API/MM-Cron | API priorities (Atul) | In this order: (1) fix duplicate and missing records (NAV duplicates are visible in the collector today); (2) nobody accesses databases directly: websites and MM-Cron must use the API (start with an inventory of every direct database reader); (3) document every column and how it is used, swagger/OpenAPI style: first search the repo and old MRs for the earlier swagger work; if none exists, generate OpenAPI from the Flask routes and write a column dictionary, catalogue tables first; catalogue APIs first (category, product/schemes), then MF APIs; catalogue features are owned by MCRM, which will extend the API beyond MF; (4) keep stgapi up (503 on every route today). Plan: https://github.com/moneymarche-dev/MMDEP/blob/main/docs/plans/sprints-2026-10-18.md | | 2026-10-17 | API/MM-Cron | MM-Cron priorities (Atul) | (1) remove database dependency (write through the API) and add logs to every job; (2) fund details for all AMCs: TER, fund size, inception date and similar; (3) AMC-reported performance and risk ratios; (4) portfolio composition. | | 2026-10-17 | MCRM | Catalogue API ownership (Atul) | MCRM owns the catalogue features of the API (category, product), first for MF, then extending to insurance products. Servicing priority is ULIP (renewals and fund enhancement); new business priority is MF SIP, Health, Term, Motor. | | 2026-10-17 | API/MM-Cron, MWMC, WPDev, MCRM | Category flags and roll-up (Atul) | Production hides categories with status/show in menu and rolls up: when a category is hidden from the menu, its children appear one level up in its place. MWMC and WPDev: report where production code reads these flags and how the roll-up is computed (file, function, query), in your next status. API: /category must return the stored flags (not 1) and offer the effective menu tree that reproduces the roll-up, with tests built from the production rule. MCRM: include the rule in the category tree design. | | 2026-10-17 | API/MM-Cron | MM-Cron jobs will be extended by agents (Atul) | Give every job a log, a registry entry and tests runnable on the laptop runner, so later agent changes go through MRs and the Test harness. | | 2026-10-17 | MCRM | ULIP is your next case (Atul) | ULIPs have product data and fund data; their funds are very similar to MFs. Take ULIP as the next catalogue family after the current one: product model plus fund model reusing the MF fund structures. Note sources: insurers' published ULIP fund NAVs (free) and Morningstar (licensed; needs an agreement, not scraping). | | 2026-10-17 | MCRM, API/MM-Cron | ULIP scope (Atul) | Data only from authentic sources through MM-Cron (Morningstar was only a reference, not a source). Start with ICICI Prudential Life ULIPs, then other insurers. Cover all active funds (a little over 30) and older funds that remain open for existing policyholders. MCRM: ICICI Prudential Life ULIP product and fund model first. MM-Cron: plan a job for this insurer's published fund NAVs (active and legacy), with logs and tests, after your current priorities. About 3,000 of our customers hold these ULIPs. | | 2026-10-17 | MCRM | MCRM destination (Atul) | MCRM's long-term role: as MMDEP is the harness for coding agents, MCRM sets up and orchestrates the harness for human and AI agents working across client data, Money Marche applications, principals' applications (insurers, AMCs) and third-party applications. Record this in your destination/VISION document as the top layer above waves 0–6; plan to reuse MMDEP's patterns (routing block, context-sensitivity preflight, trust levels, action ledger) rather than inventing new ones. Note the constraints: client data is restricted (approved, paid, India-region AI only), and actions in principals' portals need audit trails and consent (SEBI, IRDAI, DPDP Act). Don't implement now; current priority stays catalogue (category tree, then ULIP for ICICI Prudential Life). | | 2026-10-17 | PE | Run-job #336 done (exit 0, PASS) at head 27c29f33 | 25 constituents, window 2021-07-01..2026-05-22, pinned ZIP hash verified; the backslash-path fix works. Workbook and validation_summary.json: https://github.com/moneymarche-dev/MMDEP/tree/main/docs/relay/data/pe-client-review-workbook-2026-10-17 (file dated 17 Oct by run date). | | 2026-10-17 | PE | Run-job #337 done (exit 0) at head 6fc65a33 | Report shows Aggressive/Moderate replay COMPLETE (weekly 204, monthly 52), objective evaluation NOT_EVALUATED, Conservative NOT_RUN. Report and provenance: https://github.com/moneymarche-dev/MMDEP/blob/main/docs/relay/data/pe-objective-selection-report-2026-10-17.md | | 2026-10-17 | API/MM-Cron | Knowledge check: AMC master and AMFI factsheet links (Atul) | Answer in your next status, from the repository only: (1) Which API route serves the AMC list (Providers / Product Owners), and which table and columns back it? (2) Where does the repository document that AMFI's website links every AMC's monthly factsheet (AMCs must submit them; PDFs stay on AMC servers)? MMDEP found no such documentation in the laptop copies (API 20 Sep, mm-crons 5 Sep). (3) If it isn't documented, add a short document: the AMFI source, how the monthly link list reconciles our AMC list (new, closed, merged AMCs), and the planned MM-Cron job for it. Parsers for each AMC's factsheet will be built as open work packages from this list (DR-009). | | 2026-10-18 | PE | Run-job #337 rerun done (exit 0) at head bd4536cc | Report identical to the 17 Oct one (SHA-256 54eb7094…53d3): the new head only adds validation, which the committed evidence passes. https://github.com/moneymarche-dev/MMDEP/blob/main/docs/relay/data/pe-objective-selection-report-2026-10-18.md | | 2026-10-18 | ALL | Sprint 1 has started: plan it in three steps first (Atul) | Rules §16 https://github.com/moneymarche-dev/MMDEP/blob/main/docs/agents/mmdep-agent-rules.md : (1) design your sprint stories in docs/design/sprint-1/ (goal, approach, files, shared components, acceptance tests, dependencies); (2) open one issue per item; (3) preflight every issue with the routing block (cx, ctx, contract, mode, model, scope, tests, state, by). Report links, issue numbers and the preflight summary in your status, then continue normal work. Also rules §15 (quality bar) applies from today. | | 2026-10-18 | ALL | Respect Atul's time: fixed number of PROCEEDs (Atul) | Rules §16a: sprint planning takes exactly three PROCEEDs (1 = all designs, 2 = all issues, 3 = preflight of every issue), each step completed within its PROCEED. Then each epic is finished in at most three PROCEEDs: write a three-part plan in the epic issue; each PROCEED completes one part (code, tests, MR, status). Start every reply with a counter, e.g. Epic: X — PROCEED 2 of 3, end with what the next PROCEED does. If an epic can't fit, split it in the design. No questions mid-epic except rules §14 cases. | | 2026-10-18 | ALL | Where questions go (Atul) | Rules §14a: Atul answers business questions only (question-atul, one line with your recommended answer). Another project's code/data/API: ask that agent (ask-<project> issue in its repo). Process, tools, runner, jobs, unclear rules: MMDEP-PM (ask-mmdep issue in MMDEP or a line in your status). Technical detail you can decide: decide, mark ASSUMED, continue. | | 2026-10-18 | API/MM-Cron | Previous agent's handover answers | Distilled with next actions: https://github.com/moneymarche-dev/MMDEP/blob/main/docs/handovers/2026-10-18-previous-api-agent-answers.md . Key points: no OpenAPI and no data dictionary exist (create both); NAV duplicates and gaps were never measured (do a read-only audit first, no constraints or upserts without approval); /category serializer returns stored values, so verify the live database flags before blaming code; staging and production share mm_data (prove isolation before any staging write); credential MRs !168/!81/!83 need review and a person to rotate. CI is no longer blocked: use the laptop runner. |

Nudges (MMDEP Assistant, 25 Oct — 00:52 IST)

  • Sonnet / harness: nine issues (#104, #106, #112, #114, #116, #127, #133, #137, #143) were verified against merged PRs into integration/sprint-2 and closed. Finish T0 (#155) by seeding 10 ready low-risk issues; the harness still skips review/blocked work.
  • API Lane S: publish docs/relay/api-lane-s/runs/S1.md; classify the 23 API and 22 MM-Cron open MRs before staging-only steps. Do not touch production or run unapproved pipelines.
  • MWMC: start M1 and publish docs/relay/mwmc/runs/M1.md.
  • API Lane P: begin P1 from 26 Oct with the write-route security enforcement LLD; keep production/high-risk gates intact.