Owner notes — 15 Oct 2026¶
Each point: what Atul said (paraphrased), what already exists, conflicts or questions, and how and when it will be delivered.
| # | Atul's point | Exists today | Conflict / question | Plan |
|---|---|---|---|---|
| 1 | Always give full URLs when referring to documents | — | — | Rule from now (agent rules §6 addition) |
| 2 | Nothing should finish after 15 Nov; prepare two fortnightly sprints from 18 Oct, 5 milestones each | Forecast 14 Oct had A2, W2b, C2, P3 into Nov–Dec | Meeting 15 Nov needs scope cuts (A2 lite, first factsheet page, one catalogue family, P3 interim on production API) → Atul decides | Draft: docs/plans/sprints-2026-10-18.md; agree today |
| 3 | Atul flying tomorrow; two daily meetings; Claude to set alarms if needed | Scheduled tasks available (send-later into this conversation) | Times of the two meetings? | Propose two check-ins a day at the meeting times; created only after Atul's OK |
| 4 | Documentation in two places (GitLab governance repo, GitHub MMDEP): strategy and structure | Spec 0.11 §12A put estate documents in the GitLab governance repo; since 12 Oct (D8) MMDEP docs live on GitHub | Conflict with spec §12A — proposal: GitHub MMDEP becomes the programme home; GitLab governance repo becomes a frozen archive with an index pointing to GitHub | Spec 0.12 change, sprint 1 |
| 5 | Standard documentation per project; common project pages in MMDEP; cross-repo links with a short excerpt; an index page in every folder | §12A: project/estate/interface layers, IDs and versions; no index or excerpt rule | — | Documentation standard (STD-DOC-001) in spec 0.12; template set; roll-out per project in sprint 1–2 |
| 6 | Three views for every product (incl. MMDEP): (i) vision and complete design, assumptions, dependencies, roadmap; (ii) current product, issues, roadmap to production and next big release, immediate needs, dependencies; (iii) current and next milestone | Partly: plans, owner records, milestone plan | — | Three standard documents per product: VISION.md, CURRENT.md, MILESTONES.md; MMDEP keeps a page per project |
| 7 | Consolidate MMDEP specs (ex-PM specs in GitLab; Claude's spec, which Atul recalls as 1.1 — it is 0.11, approved 5 Oct); specs not maintained since the move to web / browser / terminal | docs/spec/000-orchestrator-design.md v0.11 (873 lines); ex-PM specs in the GitLab governance repo |
Spec is behind reality (TEA, local models, CLI-first, GitLab as estate home) | Spec 0.12: consolidate both sources, restructure into the three views, record web/browser/terminal tiers |
| 8 | MMDEPAD shows each product's three views (excerpts + one index link); later collapsible inline viewing in the web version | Panel has Projects section, no three-view excerpts | — | Panel change after the documents exist (sprint 1); inline collapsible in the web version |
| 9 | MMDEPAD endpoints: Claude artifact, web dashboard, MCP; switch between them at any time; agents now use GitHub instead of MCP, which won't suit other agents or GitHub-less team members | Spec §13/§15A: MCP stdio done (CLI era), online MCP gateway planned (OAuth, AWS) | Online MCP needs hosting with sign-in → AWS tools server (DR-004) | Data in one hub (DR-6); endpoints: artifact (now), Google Doc view (new, now), web + MCP (sprint 2) |
| 10 | A Google Doc copy of MMDEPAD for Atul (actions and documents), collapsible sections if possible, else TOC | Ajay's doc exists | Google Docs can collapse headings in its outline/pageless view; a TOC with heading links works everywhere | Generate from the hub/panel; refreshed by Claude now, by the controller later |
| 11 | MCP from any AI (Claude, ChatGPT, Gemini, Perplexity…): identify yourself, connect, chat | §15A design | Support differs by app (Claude, ChatGPT and Gemini CLI support remote MCP; others vary) | Online MCP gateway with OAuth, sprint 2 design, build after hosting |
| 12 | Person / project views by identity; choose the recipient when posting; Claude is default recipient; later listeners receive directly; push messaging later | Spec §7 identity rules; agent registry; panel is single-user | — | Hub: users (email), agents (registry), recipients per message; views filtered by identity; push options study (email, WhatsApp/Telegram bot, app push) |
| 13 | Labels for agents, tools, humans are good; harden identity later | Labels in use | — | Keep; identity hardening in spec 0.12 §7 |
| 14 | New rule — durable notes and evaluation: don't assume Atul remembers the background; record what he says in durable notes; check current documentation; tell him what exists, how and when it will come; raise disagreements; propose new features; don't implement immediately unless prioritised — plan through issues | — | — | Agent rules §13 (all agents); this file is the first application |
| 15 | Update modes: available-to-discuss vs on-the-go one-way; design verbs like PROCEED / CONTINUE | PROCEED / CONTINUE / STATUS / HOLD / REDUCE exist (agent-facing) | Need Atul-facing verbs for how Claude reports to him | Proposal: TALK (I'm available, discuss), BRIEF (one-way, short, no questions), NOTE (record only); agree today |
| 16 | Sort issues periodically: unattended-scheduled vs attended (browser) runs; verify CLIs work both ways | — | — | Weekly triage label run:unattended / run:attended; controller does it later |
| 17 | Atul will copy weekly chat transcripts per agent for audit against MMDEPAD | — | — | Store under docs/audit/chats/<agent>/<week>.txt (no secrets; Claude checks before commit) |
Additions — 15 Oct, 12:54 IST¶
| # | Atul's point | Exists today | Conflict / question | Plan |
|---|---|---|---|---|
| 18 | Sprints are agile, value-maximised: value of a milestone falls with distance; fill the nearest two sprints fully, pulling forward lower-value but ready items from the whole backlog; stories move by value and dependency. Not "everything in two sprints" | Draft S1/S2 tried to compress everything by cutting scope | My earlier reading was wrong; the draft is redone as a value-ordered backlog with pull-forward candidates | docs/plans/sprints-2026-10-18.md rewritten |
| 19 | SuiteCRM is lowest priority until after these two sprints | SuiteCRM items in API/MCRM plans (credentials, integration validation) | Security of exposed SuiteCRM secrets (SEC-2) still needs the rotation; only integration work is deferred | SuiteCRM integration and CRM stream items moved to the back of the backlog; secret rotation stays |
| 20 | Push any document branch (project or programme) to a Google Doc, like the MMDEPAD Google Doc | — | — | mmdep docs push --repo --branch --path to a Google Doc per folder index (sprint 1–2 story) |
| 21 | Comments and messaging via Google Apps Script for an MMDEPAD feel in Google Docs | DR-5 (withdrawn) had Apps Script | Fine as an endpoint over the same hub | Apps Script on the Google Doc view: comment → hub message (sprint 2 story) |
| 22 | MMDEP CLI should use PowerShell editing, Notepad or vi for text input, and offer MCP options | CLI exists (CLI era); $EDITOR not used |
— | mmdep respond/raise --edit opens the user's editor; MCP stdio server already exists |
| 23 | Web MMDEPAD: small implementation on Bluehost (minimal DB), desktop CLI serving it; MongoDB Atlas if needed; GitHub/GitLab can extend MCP | Spec §15A said Bluehost unsuitable for a long-running gateway | No conflict for a small PHP + MySQL page with sync pushed from the desktop (no long-running process); MCP gateway still needs a host that keeps a process (Atlas or GitHub alone cannot run it) | Sprint 2 story: Bluehost PHP page + MySQL, desktop mmdep serve --push; MCP: evaluate a hosted serverless option |
| 24 | AWS is deferred, not stalled | DR-004 | — | Keep DR-004; revisit at sprint 3 planning |
| 25 | Sprints must reach, or show visibility of, break-even (BEP); plan 2–4 sprints now, a full-year calendar later; investment follows plans versus performance | No cost or revenue model exists | Needs figures: monthly costs (subscriptions, hosting, people) and revenue drivers (traffic, leads, conversion, commission per product) | BEP model in docs/plans/bep-model.md once figures arrive; each sprint shows its expected contribution |
Additions — 15 Oct, 13:39 IST¶
| # | Atul's point | Exists today | Conflict / question | Plan |
|---|---|---|---|---|
| 26 | Context segregation for MCP (and every endpoint), not only identity | Spec §5B: engines tagged with allowed data classes (public, synthetic, internal, client); free tiers get public/synthetic only; §15A field allowlist for the online view |
Today every member needs full repo access; no per-person or per-project scoping exists in practice | Access scopes: each identity gets projects × data classes × actions; the hub serves only what the scope allows, on every endpoint |
| 27 | Induct people today only with full access; need employees by role, gig workers for specific jobs, agencies (one-time or long term) | No role model beyond Atul/Ajay/agents | — | Engagement types (employee, gig, agency, agent) with default scopes; a gig worker or agency sees a task pack (the task, its excerpts, its data), not the repos |
| 28 | Free AI for some work, risk limited to what we share | Principle 8 and §5B (free tier = public/synthetic) | Matches the spec; needs enforcement in the job/task pack generator | Task packs are generated with only allowed classes; redaction as second line; free engines registered with public/synthetic |
| 29 | Easy induction for any new agent or person: MMDEP framework, project scope, product background | Agent onboarding pack (12 Oct artifact), agent rules, project instructions | Packs are per agent and manual | Induction pack per role and project, generated from the three-view documents (vision, current, milestones) + rules + scope; same pack for humans and agents; level of detail by scope |
Additions — 15 Oct, 14:39 IST¶
| # | Atul's point | Plan |
|---|---|---|
| 30 | Specs have a High Level Design, with items drilled down to a Low Level Design; an LLD must exist before an item is planned into a sprint | Spec 0.12 structure: HLD (vision, architecture) + one LLD per item; sprint planning rule "no LLD, no sprint" (agent rules and sprint template) |
| 31 | Evaluate current status and plan the documentation and design process for the other projects too | Documentation audit per project (what exists vs the standard) as a sprint 1 story; PE and MWMC first |
| 32 | Claude weekly credits 75% used; reset Saturday 18 Oct, 19:30 IST. Until then sprint 0; sprint 1 starts at the reset | Sprint dates: S1 18 Oct 19:30 → 1 Nov; Claude work in sprint 0 limited to tonight's Google Docs and verification |
| 33 | Verify how the ChatGPT schedulers run and contribute; if unattended runs cannot write to repositories, give them another tool (for example Gmail) that the attended session can read through a connector | Tonight: check each scheduler's last runs; test an unattended write path (email draft or Google Doc) |
| 34 | Two Google Docs tonight (MMDEP Actions, Documentation) for offline reading in flight; may test the mmdep CLI offline | Docs tonight; offline steps below; CLI offline test with a scratch hub only |
Additions — 15 Oct, 15:03 IST¶
| # | Atul's point | Plan |
|---|---|---|
| 35 | Back up ChatGPT agent chats (projects first, older chats later) | Use ChatGPT's data export (one archive per account) instead of copying chats one by one; raw archives in a private Drive folder; decisions extracted into owner notes per agent (GenAI job, not Claude) |
| 36 | Prompt all agents today about the new process and update their hourly scheduler tasks; repeat once to verify | Draft prompt tonight; verify after two scheduled runs |
| 37 | Close the loop: collector is one-way to the laptop; agents should get Claude's responses directly. Run Claude on a schedule (every 4 hours, fully online) | Collector pushes its snapshot to a private GitHub repo (mmdep-control); a scheduled online Claude task reads it and writes responses to answers.md and the issues; frequency tuned to credits |
| 38 | Re-initiate the ChatGPT MMDEP assistant as a collector backup and to take over work that saves Claude credits; test its tools first | Test tonight: can a scheduled ChatGPT run read GitLab/GitHub and write to GitHub or the Google Doc drop box; if yes, it drafts routine relays and summaries, Claude reviews |
Additions — 17 Oct, 17:41 IST¶
| # | Atul's point | Plan |
|---|---|---|
| 39 | When will the Gemini API be tested in actual use? | Planned for sprint 2 (D2). Proposal GEM-1: first real use in sprint 1, week 2, as read-only Flash-Lite test triage (DR-007 §4) |
| 40 | Split the harness into Design, Code and Test streams; ensure reuse and cross-project dependencies. Design covers existing, immediate goal and long-term goal; Code does current-phase issues and bugs from Test; Test designs and runs unit, UAT, performance and other tests periodically and on every release | DR-007 §3: programme-wide Design and Test harnesses, per-product Code; hand-off by labels; shared-components register; MWMC pilot in sprint 1 (HAR-1) |
| 41 | On-demand agents (Claude or ChatGPT APIs, hosted containers for short bursts) with measured usage; cost vs subscriptions or infrastructure upgrade | DR-007 §5: subscriptions for attended work; metered APIs for unattended work only, capped at ₹3,000 a month; laptop runner first, then GitHub Actions minutes, Codespaces bursts, AWS tools server on evidence (ODM-1) |
| 42 | Modes per harness: Design attended in the browser with Atul, able to schedule research and tests with the other harnesses; Test on the laptop within capacity (low now, legacy only; grows with releases); Code in all three modes | DR-007 §3 "Operating modes": Design files research / test-request / lld-ready issues; Test on the laptop runner with a capacity rule; Code attended, scheduled (metered API + runner) and on-demand burst (Codespaces) |
| 43 | Revenue: plan two metric sets, new business (slow to yield) and customer support (immediate: renewals, growth of client portfolios) | docs/plans/bep-model.md: servicing metrics S1–S8, new business N1–N6, break-even R_s + R_n ≥ C, product work mapped to metrics; figures still needed (BEP-1) |
| 44 | Browser harnesses communicate through the repository, so Atul need not relay prompts; his standard verbs work; agents don't ask him when they need nothing | DR-008 §1: queues as for:<harness> issues; full instruction in the issue; verbs PROCEED/CONTINUE/STATUS/HOLD/REDUCE defined for all agents (RTE-1) |
| 45 | Code harness preflight splits work by complexity and context sensitivity; assign agents and models per task; feedback on labels; can an issue suggest the model; second Claude project for a lower model; Claude stays on Opus and delegates | DR-008 §2–5: cx/ctx/contract/mode labels, routing table, YAML routing block; label review with alternatives; model auto-selected in API modes, suggested only in browser modes; second Claude project (Atul picks Sonnet per chat); keep/delegate table (PRE-1, CLP-1) |
| 46 | Context segregation: GitLab "branch-level security"; plan GitLab now, GitHub later | Correction: protected branches control push/merge, not reading; read segregation is per project membership. DR-008 §6 plan (SEG-1) |
| 47 | Evaluate an MMCLONE-style satellite repository per task, full-code deployment for testing, to hire outside developers with absolute segregation | DR-008 §7: workflow, pros/cons, pilot after sprint 1 on a self-contained item (SAT-1) |
| 48 | Paid AI agents may read code anywhere but must read only the code the branch or issue needs (memory); hiding is for free agents and outside developers. Untrusted outside developers get only new features or modules that don't touch the core | DR-008 §6a: scope: block in the routing block, context packs for API runs; §7 trust levels T0–T2, restricted context never to outsiders |
Additions — 17 Oct, 19:48 IST (business priorities)¶
| # | Atul's point | Plan |
|---|---|---|
| 49 | Customer support priority: ULIP renewals and ULIP funds enhancement (largest customer base) | BEP model and sprint plan: ULIP renewal due-list first (replaces generic renewal reminders in SPR-2); ULIP fund enhancement needs ULIP fund NAV data per insurer, which the API/MM-Cron don't hold today → question ULIP-1 (meaning and data source) |
| 50 | New business priorities: MF SIPs, Health, Term, Motor. Sales and support people per vertical through an outsourcing agency; pilot running with 1 motor-insurance resource | BEP new-business metrics per vertical; agency staff are CRM/operations users, not code contributors (segregation by CRM roles, not repos); motor pilot gives the first acquisition-cost figures |
| 51 | API priorities: (1) fix duplicate and missing records; (2) nobody accesses databases directly: websites and MM-Cron use APIs; (3) document every column and its use (swagger-type docs; earlier API agent was asked) ; catalogue APIs first (category, product/schemes), then MF APIs; catalogue features owned by MCRM, which will extend the API beyond MF; (4) stgapi up and running. Atul can share TEA chat records for background | No OpenAPI/swagger found in the laptop copy (20 Sep); partial contracts exist (docs/mf-catalogue-api-contract.md, docs/mf-summary-timeseries-api-contract.md). API agent checks the live repo; if absent, generate OpenAPI from code and ask the previous agent (API-DOC). Relayed in answers.md |
| 52 | MM-Cron priorities: (1) remove database dependency (use APIs) and build logs; (2) fund details for all AMCs (TER, fund size, inception date, …); (3) AMC-reported performance and risk ratios; (4) portfolio composition | Relayed in answers.md; sprint plan updated |
| 53 | Ajay, MWMC and WPDev were asked to find where production uses the category status and show in menu flags (the API doesn't return them); production also rolls up categories: a category hidden from the menu has its children shown one level up |
Known since 13 Oct (API returns 1 for both flags; menu code reads the database). Roll-up rule added to the owner record §11; API to return real flags plus the effective menu tree; agents' findings collected through the relay |
| 54 | MM-Cron job scripts may be extended by agents in future | Every job gets logs, a registry entry, tests and the laptop runner; agent changes go through MRs labelled for Test (DR-007) |
| 55 | ULIPs have product data and fund data; ULIP funds are very similar to MFs; MCRM has studied or is studying this and should take ULIP as its next case | ULIP becomes MCRM's next catalogue family after the current one; ULIP fund data reuses the MF fund model (NAV, performance, risk) |
| 56 | Morningstar shows data for both MFs and ULIPs | Possible source, but Morningstar data is licensed: using it needs a data agreement, not scraping. Free primary source: the ULIP fund NAVs that insurers publish on their own websites; Morningstar as a paid option to evaluate (ULIP-1) |
| 57 | Morningstar was only a reference for the MF/ULIP similarity. ULIP data comes through MM-Cron from authentic sources only. Start with ICICI Prudential Life ULIPs, then other insurers. About 30+ active funds, plus older funds still needed for existing policyholders. About 3,000 customers hold ICICI Prudential Life ULIPs | ULIP-1 closed. MM-Cron: ICICI Prudential Life ULIP fund NAVs from the insurer's own published data, active and legacy funds; MCRM: ICICI Prudential Life ULIP product + fund model first; BEP S0 uses the ~3,000-customer book |
| 58 | MCRM's destination: like MMDEP is the harness for coding agents, MCRM sets up and orchestrates the harness for the work of human and AI agents moving between client data, Money Marche applications, our principals' applications (insurers, AMCs) and third-party applications, once we mature | Exists: MCRM waves 0–6 (Party/KYC, Dossier, Sales, Documents, Integration, Operations) cover the pieces but not the orchestration role. Plan: MCRM's VISION gains an 'operations harness' layer; reuse MMDEP patterns as shared components (routing block, preflight by context sensitivity, trust levels, heartbeat, ledger of every action and its cost). Conflicts to watch: client data is restricted, so AI agents act on it only on approved, paid, India-region providers; actions in principals' portals act as a licensed person and need audit trails and consent under SEBI/IRDAI rules and the DPDP Act (check with the compliance adviser). Not for implementation now; MCRM records it in its destination document and plans it after the catalogue families |
Additions — 17 Oct, 23:09 IST¶
| # | Atul's point | Plan |
|---|---|---|
| 59 | Quotes start from non-sensitive data, refined iteratively with the client; B2B partners don't share real data until they decide to transact. Initial quotes should be low-cost: free agents and tools | DR-009 §1: new indicative class (no identifiers) allowed on free tools; identity moves work to client (DCL-1) |
| 60 | Much project research on public data can be done with free tools before scripts are final, to pre-empt real-use issues. Example: monthly parsing of factsheets from about 50 AMCs, none working today (8 to be built, per Atul). Give such requirements to free coders or free accounts; use their code and data after security checks | DR-009 §2: open work packages; AMC factsheet parsers as the first candidate (OWP-1) |
| 61 | Define projects with precise requirements outside the framework, host them for free agents or gig workers, merge if they meet acceptance criteria; many such use cases | DR-009 §2: package contents, intake (tests, security, data check), register |
| 62 | Extendability also means extending subscriptions: Claude allows buying extra credit; ChatGPT Go has no extra credit but is free in India until Dec 2026 (₹399/month after), so Go accounts can go to other developers and users | DR-009 §3 (SUB-1); one account per person |
| 63 | The AMC list already exists in our Providers / Product Owners API. AMFI's website links to every AMC's monthly factsheet (AMCs must submit them; PDFs stay on AMC servers). These links also reconcile our AMC list: additions, closures and mergers show up. This should be documented by the API/MM-Cron agent; use it to check how up to date the agent is and whether the repository carries it | Checked the laptop copies (API as of 20 Sep, mm-crons as of 5 Sep): API has a product-owner controller but no mention of AMFI factsheet links or AMC reconciliation; mm-crons uses AMFI only for NAV history and AUM, plus one ad hoc ICICI factsheet parser on a local July-2024 PDF. Not documented. Relayed as a knowledge check to the API/MM-Cron agent; DR-009 factsheet packages now start from the AMFI link list, with a monthly reconciliation against the Providers API |
| 64 | Keep reviewing regulator and official sites regularly and update ourselves on changes: AMFI, SEBI, APMI, exchanges (MF/investments); RBI and CRISIL (AIF information); IRDAI (insurance); RBI (finance); income-tax rules; government macro data; then principals. AMC factsheets also carry economic data we ignore today | docs/registers/watch-sources.md (W1–W11); Design backlog DS-1 (watch) and DS-5 (factsheet economic content) |
| 65 | Confirmed: AMFI links are not used to maintain the AMC list; factsheet links may be hardcoded (risk if an AMC moves them; it must inform AMFI); second risk: format changes by AMCs | Design backlog DS-2 (reconciliation), DS-3 (always resolve links from AMFI), DS-4 (parser contract, layout fingerprint, quarantine on change) |
| 66 | These questions belong with a Design agent, missing today; use such samples to make processes robust | Design backlog seeded (docs/design/backlog.md); project instructions ready (docs/agents/projects/design-harness-instructions.md); Atul task DES-SET |
| 67 | Keep the Design set-up in the actions, but check capacity and dependency before allocating anything: Atul is on vacation and a Design agent needs his time; coding and testing agents must be set up first | DES-SET moved to 'Later' in the panel, blocked by Code + Test harness and Atul's return |
| 68 | Phase 1: once Code + Test is ready, convert the existing ChatGPT agents to Design + Preflight agents that design an entire epic (today: up to 5 issues, iteratively); keep 2 harnesses first, not 3 | DR-007 §3b; sprint plan updated |
| 69 | Claude as super-designer for 2–3 projects each | DR-007 §3b: proposed grouping (data+catalogue, websites, analytics+programme) |
| 70 | Did we study OpenRouter for cheaper models and its cost? | Not before; now in DR-007 §5: 5.5% fee, pass-through prices, fallback routing, free tier for evaluation only; proposal: $10 benchmark of cheap models for preflight and triage |
Additions — 18 Oct, 00:12–01:00 IST¶
| # | Atul's point | Plan |
|---|---|---|
| 71 | Set up the Code + Test harness for MMDEP itself as the model case, and implement it. Evaluate low-memory SLMs and helpers (Qwen2.5-Coder 1.5B/7B, DeepSeek-Coder 1.3B, Aider, OpenCode) for 8–16 GB old machines, and automation triggers (git hooks, webhooks, CI/CD, file watchers, cron, Lambda) | Harness built (mmdep/harness.py), pilot issue #14; DR-010 |
| 72 | Merge approved with conditions: the monthly cap includes one-off purchases (minimum top-ups for Gemini API, OpenRouter, Hugging Face and similar); paid API use through separate Claude and ChatGPT API accounts, not the current subscriptions; free quotas first, paid models by criteria; objective: visible results each sprint | harness spend + spend.csv count toward the cap; free-first model chain with allow_paid gating; Anthropic and OpenAI-compatible (OpenAI, OpenRouter) backends with separate keys |
Additions — 18 Oct, 09:29 IST¶
| # | Atul's point | Plan |
|---|---|---|
| 73 | Code and test quality must never be compromised; agents respect common libraries; refactor periodically | Rules §15; harness gates (lint, dependencies, tests with code); components register in prompts; duplicate finder at sprint end (merged 18 Oct) |
| 74 | The scheduled check-in waited for approval to re-schedule itself and to write the panel: fix so it never waits | Replaced by a recurring scheduled task 'MMDEP check-in' (08:50 and 19:50 IST) running with automatic approval and a runbook (docs/harness/check-in.md); old self-rebooking task deleted |
| 75 | Sprint 1 started: all agents plan in three steps (design, issues, preflight), then work normally; Claude too | Rules §16; relay row to all agents; fresh prompts start with it; MMDEP design docs/design/sprint-1/mmdep.md, issues #17–#25 |
| 76 | Pick the top 5 candidates to test the code harness and assign them to code | #17–#21 (shared shell runner, duplicate finder options, chat archive env default, ledger summary, routing-block linter), plus #16; all mode: scheduled, cx 1 |
| 77 | Sprint planning in exactly 3 steps with Atul's 3 PROCEEDs; then each epic in at most 3 PROCEEDs. Browser agents lack Codex's /goal, so the limit must be in the instructions | Rules §16a (counter at the top of every reply, three-part plan per epic, split if it can't fit, no mid-epic questions except §14); relay row; fresh prompts updated |
| 78 | MMDEP Assistant as the online answer when the laptop is down: PROCEED for backlog, sort the panel, update responses, run critical GitLab/GitHub pipelines on the cloud; from sprint 2 use each GitLab group's free minutes judiciously; check GitLab policy and members/roles so each group gets 400 minutes without clashes; move repos if needed | DR-011: minutes are per top-level group (roles don't matter); 4 groups = 1,600 min/month; all groups ≤3 users; proposals GLB-1 (move webapp-sakai to the websites group), CHK-2 (cloud-only check-in), FBK-1 (hosted-fallback CI); assistant ONLINE MODE prompt added |
| 79 | GitLab: 3 groups per user, so 5 users could own up to 15 groups; give heavy repos their own group and keep blank groups ready to move repos into when a group's minutes run out mid-month | Advised against the standby-group rotation: it works around GitLab's free quota and its abuse guidance lists mass creation of groups as disruptive, with accounts blocked; risk to production repos outweighs the minutes. Alternatives: self-hosted runners (laptop + old machines, unlimited), buying minutes (about $10 per 1,000, rolls over), product groups where genuinely needed (GLB-1). Group creation stays Atul's decision |
| 80 | MMDEP Assistant and every job (local Gemini or other models, desktop tools) follow the heartbeat and do incremental work only, with flags/reports updated so desktop tools also stay incremental | Rules §17; docs/registers/flags.md (state file per job); harness skips failed issues until they change (harness/state.json); check-in runbook and assistant prompt updated |
| 81 | Agreed: no repository moves after the first allocation to groups. Blank groups kept only for future repositories. New repositories for MMCLONE-style testing (satellites) in GitLab and GitHub at the right time; gig workers never get access to our code or desktop | DR-008 §7 satellite pilot (sprint 3) uses new repositories; GLB-1 is the one first allocation |
| 82 | MMDEP Coding (Sonnet) was holding in a design phase waiting for Atul; give it only already-approved tasks | Comment on #27 marking it approved (design B1 under SPR-1); Sonnet instructions: routed state: ready items are approved work, implement in the first PROCEED |