diff --git a/operating-model/decision-log.md b/operating-model/decision-log.md index f052ff5..8e0a88b 100644 --- a/operating-model/decision-log.md +++ b/operating-model/decision-log.md @@ -41,3 +41,4 @@ Status is intentionally explicit: | 2026-09-29 | Confirmed | The agent launched on a work board is a dispatcher: one fresh, clean-context sub-agent per job, one at a time, up to five jobs per run, then a full stop until a human says go. | Owner: "ideally, you want each agent to work with a clean context, then each agent is launching a sub-agent be the model then, so subagent finishes a bead and changes bead status and reports back to parent agent. parent agent at any point in only running a single sub agent. after the sub agent finished, the parent agent is lanching the next one in a loop, up to a maximum of five and then completely stop until human asks it go again for another five". The dispatcher only reads the board, claims, launches, reads the report and logs; the sub-agent does one job and makes its board transition. Refines the 2026-09-28 work-loop row: the loop and priorities stay, the agent that runs them changes. See `agent-work-loop.md` sections 2, 3, 4 and 6. | | 2026-09-29 | Confirmed | Projects keep their launch prompts as named, versioned files in the repo, with an index; a launch is one line naming the prompt and its path, plus parameters; the run report names the prompt version it ran. | The owner approved the lead's design ("go") for replacing pasted launch text with checked-in prompts, so a launch is repeatable and a report says which prompt version produced it. Adds to the 2026-09-29 dispatcher row. See `agent-work-loop.md` section 7. | | 2026-10-08 | Confirmed | The owner's cross-project rules live here in vendor-neutral words so any agent works the way the owner wants in every repository: model tiers (deep, standard, light, premium) with a vendor mapping, premium launches only on the owner's per-launch yes, ask before any new service, monitor, workflow or scheduled wakeup, never set a spend cap ($0 by default), they/them for the owner, a fresh brief for a scope change, files only under `~/work`, scratch in the harness's scratchpad or `~/work/code/mastrix/worktrees/--notes/`, never `/tmp`, and a vendor-neutral checkpoint procedure. | Owner, R1008-27: "n1-n8 is good", accepting decisions D1-D8 of the agent-neutrality plan as recommended, and: "any agent can work exactly like the way I want it to on the repo". Sources: the owner's rulings of 2026-09-27, 2026-10-05 and 2026-10-06 as kept in the Claude memory files. Supersedes the vendor-named tier wording of the 2026-09-21, 2026-09-23 and 2026-09-27 rows (they stay as history) and the 2026-09-27 scratch-path example. See `working-style.md` → Model tiers, `execution-and-handoffs.md` → Scratch files and agent worktrees, and `procedures/checkpoint.md`. | +| 2026-10-12 | Confirmed | Inquiry sessions are question-only sessions to understand a project; artifacts stay local and agents proactively propose consolidating answers into FAQs, documents, diagrams or tables. | Owner: "This is only a session for asking questions. We'll name it 'inquiry'... remember to propose it either as an FAQ, a section, a document, a README, a diagram, or a table." See `working-style.md` → Confirmed preferences (Inquiry sessions). | diff --git a/operating-model/working-style.md b/operating-model/working-style.md index d1fdaca..fa253ca 100644 --- a/operating-model/working-style.md +++ b/operating-model/working-style.md @@ -20,6 +20,7 @@ starting work. | Execution release | Detecting that a prerequisite is satisfied is not progress unless it releases the next safe action. | Maintain an explicit next-action queue for each active dependency; when a merge/check/review satisfies its condition, dispatch the queued leased task in the first writable turn and report the dispatch, not merely the observation. | | Data location (Mastrix organization, owner 2026-10-05) | Every file saved for Mastrix work (data, exports, generated views, extracts) lives under `~/work`: `~/work/projects/mastrix/...` or `~/work/code/mastrix/...`. | Never write to `~/Desktop`, `~/Documents`, `~/Downloads`, `~/` itself or any other first-level folder of `~` (for example `~/mastrix-data`). Commands given to the owner and agent briefs name a `~/work/...` path. Scratch and worktrees: `execution-and-handoffs.md` → Scratch files and agent worktrees. | | Shared Mastrix repositories (Mastrix organization, owner 2026-10-05) | Every Mastrix project always includes `~/work/code/mastrix/mastrix-core` (the shared contracts, architecture and rules; core wins) and `~/work/code/mastrix/product-strategy` (the product strategy; the use cases are described there by Karthik, e.g. `product/use-cases/demo-use-cases/`). | Add both directories to every Mastrix session and project. `git fetch` both and read `origin/main` before designing, planning or describing a use case, never a stale checkout. Treat the use cases as Karthik's documents, not as reconstructions from other repos. `product-strategy` is read-only: no branches, commits or PRs there; produce files or patches in the scratch location and hand them to the owner. `mastrix-core` is read-only unless a project rule or the owner separately authorizes a PR there. | +| Inquiry sessions | A session the owner names an "inquiry" is question-only, to understand a project (first: Mastrix DIS). Agents answer from evidence, stay read-only on the project, keep every artifact local, capture Q&A as they go, and propose a fitting consolidation (FAQ, section, document, README, diagram, table) once a body of answers is big enough. | Save under `~/work/code/mastrix/inquiry/` (index `README.md`, `faq/`, `docs/`, `diagrams/`), never in a repo or `~` first level. Append each substantive answer to `faq/.md` with date, commits and `path:line` evidence; propose a consolidated form at about three answers on one topic or when an answer will be reread, and wait for a yes. Report defects to the project's lead in one line rather than fixing them. Canonical text lives in the project's `inquiry/OPERATING-RULE.md`. Owner, 2026-10-12. | | Code quality gate | Every code change must satisfy the repository's language- and project-specific formatter and linter before commit. | Discover the configured tools from the project, run both on changed code (and the required project gate when practical), fix findings rather than merely reporting them, and record the commands/results in the handoff. | | State clarity | Task implementation, independent review, CI, and integration are distinct states. | Name the exact state, owning boundary, newest durable evidence, and smallest safe action; do not collapse a passing test, open PR, or branch into an integration claim. | | Interface governance | Cross-cutting operator interfaces need one canonical contract before staged implementation. | Map each command or capability to one owning gate and its dependencies; link to the canonical interface rather than creating parallel designs. |