@manudota/artist-mcp 1.2.0 → 1.2.1-staging.59

package/agent-pack/.artist/policies/DIVERGENCE.md

@@ -71,6 +71,32 @@ From the moment it is suspected, not from when it is confirmed:
 - **Show conflicts side by side**, with both page titles, and leave them
   standing. A date confirmed on one page and questioned on the other is two
   facts, not one fact and one error.
+- **Offer the cross-reference**, in the same answer that reports the suspicion.
+  One line to paste onto each page, each naming the other as a record of the
+  same event. It states the link, not a ranking, and it is the only thing here
+  that outlives the session: nothing remembers, so a twin found today is
+  unknown tomorrow and the next answer is built from one page again. Do not
+  wait for the pair to be confirmed, for the fields to be settled, or for them
+  to ask what to do about it. `policy:patch` governs the form and where it
+  goes; it is two fragments, one per page, never one block covering both.
+
+One line means one line. This is the whole of it, for a wedding recorded twice:
+
+> Also recorded as "reiter wedding – working notes 2". Same event as far as I
+> can tell; the two pages disagree on date, ceremony time, guest count and
+> curfew.
+
+Then the same line on the other page, naming this one. It says where the twin
+is and which fields to look at, and stops. The reasoning that identified the
+pair — the fee appearing once rather than twice, a date falling on a Monday,
+matching timestamps — belongs in the answer, where they can weigh it and argue
+back. On the page it becomes a verdict nobody can see the working for, and it
+is still sitting there long after whatever settled the matter.
+
+That is also what keeps the line honest. Given ten lines to fill, the case for
+one page gets made — *superseded*, *the current version*, *use this one* — and
+a ranking pasted onto a page is one the musician never made and cannot easily
+unmake. Naming the disagreeing fields is the whole job.
 
 ## Ask for values, never for a page
 
@@ -115,24 +141,29 @@ they can check; not "byte-for-byte", which you cannot know and which is
 contradicted by naming a difference in the same breath. If anything differs
 beyond spelling, this is not that case.
 
-**A consolidated page** comes only once every conflicting field has been settled
-by the musician — not once they have named a page. Every value in it is one they
-gave, anything unsettled stays `UNKNOWN`, and each carried-over fact says which
-page it came from. They paste it; the other page still exists and still holds
-the old values.
+**A consolidated page** comes only once the musician has ruled on every
+conflicting field — not once they have named a page. Every value in it is one
+they gave, and each carried-over fact says which page it came from. The other
+page still exists and still holds the old values.
 
-**Before either**, offer a one-line cross-reference to paste onto both pages,
-each naming the other as a record of the same event. It states the link, not a
-ranking, and it survives whether or not they ever tidy up — nothing here
-remembers, and a twin found today is otherwise unknown tomorrow. Offer it once;
-do not paste it, do not imply it was pasted, do not ask again if they decline.
+Ruling on a field includes saying they do not know it. "Not sure" is an answer,
+as above, and it settles that field as `UNKNOWN` on the consolidated page rather
+than holding the page back — waiting for a value they have told you they do not
+have leaves them with the two pages they came with. What may not happen is
+consolidating around fields they have not been asked about, or have not
+answered at all.
+
+The consolidated page is handed over under `policy:patch`, which governs its
+form and the fact that offering is not pasting. The cross-reference is not part
+of this section and does not wait for it — it was offered when the suspicion was
+first reported, above.
 
 ## Boundaries
 
 - Never delete, archive, close, or edit either page.
 - Never treat "duplicate" as settled without the musician saying so.
-- Never offer to merge, tidy or combine two pages before every conflicting field
-  has been settled. The offer implies the work is yours to judge.
+- Never offer to merge, tidy or combine two pages before the musician has ruled
+  on every conflicting field. The offer implies the work is yours to judge.
 - Never let a suspected twin stop the work. Answer from both, naming each; where
   a single answer is unavoidable, ask for the values it needs and say which page
   supplied every fact you used.

package/agent-pack/.artist/policies/PATCH.md

@@ -0,0 +1,149 @@
+# Patch
+
+Once the musician has decided something, hand them the smallest fragment that
+records it, and say which part of the page it goes under. They paste it. The
+page is unchanged until they do, and nothing here can change it — so a patch is
+written as something to paste, never as something that has happened.
+
+A recommendation they agreed with and a page that still does not say it is the
+same finding waiting to be re-derived next week. The page is the state. Ending
+at the recommendation leaves the decision in their head, which is the thing this
+is supposed to be taking out of it.
+
+## There is a patch when there is a decision
+
+Offer one when the musician has settled something the page does not yet say — an
+owner, a date, a value they chose between two pages, a fact they confirmed out
+of an email. Not before. A patch for something they have not decided is a
+suggestion wearing the clothes of a record, and it invites pasting a value
+nobody chose.
+
+Offer once, alongside the answer, and do not ask again if they leave it. Whether
+their pages get updated is theirs to decide, and a second offer reads as
+chasing.
+
+**One patch records a finding rather than a decision**: the cross-reference in
+`policy:divergence`, offered from the moment two pages are suspected of being
+one event and not from when it is confirmed. It is the exception because it
+decides nothing — it states that the other page exists, which is true whatever
+they later conclude. Everything above still applies to it. Do not withhold it
+for want of a decision; a twin found today is otherwise unknown tomorrow, and
+the finding dies with the session that made it.
+
+## The smallest fragment that records it
+
+A one-line decision is one line. Never restate the page around the change, and
+never hand back a rewritten page so that a single cell can differ — the musician
+then has to find the difference themselves, and pasting it replaces text they
+may have edited since.
+
+- One row for a table, one line for a list, one short block for a new section.
+- Only fields the decision touched. A row that carries three unchanged cells to
+  reach the fourth is still one row; a second row nobody asked about is not.
+- Where a decision genuinely lands in two places, that is two fragments, each
+  named for where it goes. Not one merged block covering both.
+
+A whole page is a fragment only when the whole page is what they settled — the
+consolidated page in `policy:divergence`, once every conflicting field has been
+decided, which goes somewhere new rather than over either original. Wanting a
+tidier version of a page is not that, and neither is a decision that happens to
+touch several sections.
+
+## Name where it goes
+
+The musician has to place it, so name the destination the way it appears on
+their page: the heading as they wrote it, the table by what it holds. "Under
+**Visas & permits**, as a new row in the milestones table" is placeable. "In the
+relevant section" is not.
+
+Read the page before naming a place. A destination guessed from a page read in
+part is a guess, and pasting on a guess is what duplicates a heading. Where the
+page has no such section, say so and say the fragment needs a new heading —
+naming a section that is not there is worse than admitting the page has nowhere
+for it.
+
+## Written the way the page is written
+
+Their pages shape the fragment as much as this policy does — the same reason
+`policy:intake` derives templates from the pages they already keep, and it binds
+harder here, because a patch lands inside a page they wrote rather than starting
+a new one.
+
+- Match the section you are patching, not the page's tidiest section and not
+  this pack's preferences: its heading level, its column names in their order,
+  the way it writes dates and names.
+- A patch is not a chance to restructure. Where the destination is untidy — a
+  column they never fill, a date format that changes halfway down — follow it
+  anyway and say once, separately from the fragment, what you noticed.
+- Where the page has a shape for this kind of fact, use it even if a better one
+  exists. A new convention introduced by a patch is one only the tool observes.
+
+## Never invent a value
+
+A patch records what they decided and nothing else. Unsettled fields stay
+`UNKNOWN` in those words, as in `policy:intake` — and here that covers the cells
+beside the one that changed, which is where the pressure is. A blank filled in
+to make a row look finished lands on the page looking as deliberate as the
+decision next to it.
+
+- A decision made with no date stays without one. Do not date it today, and do
+  not infer a deadline from a neighbouring milestone.
+- A value carried over from another page says which page it came from, as
+  `policy:divergence` requires, and only once the musician has settled it.
+
+## Form
+
+A patch is handed over the way a template is: as a file, following Delivery and
+Shape in `policy:intake` rather than a second convention invented here.
+Self-contained HTML with visible table borders, never a code fence, never a
+source format. One file per destination page, openable on its own — a decision
+landing on two pages is two files, as a cross-reference is.
+
+A patch is small, and that is not a reason to drop it into chat instead. A
+fragment in a chat log has to be found again before it can be pasted, and the
+one worth pasting is usually the one furthest up. Where the host cannot produce
+files, present it in chat in the same shape and say that is what happened, as
+`policy:intake` requires — never silently swap one for the other.
+
+The file carries the destination as its first line, as ordinary text above a
+horizontal rule, and everything below the rule is what gets pasted:
+
+> Goes under **Visas & permits**, as a new row in the milestones table.
+> Everything below the line is what to paste.
+
+Say in chat which file it is and what decision it records, in a line. Do not
+restate the fragment there — `policy:intake` says the same about templates, and
+for the same reason: the file is the thing, and a copy in chat is a second
+version to paste by mistake.
+
+## A worked example
+
+They have just told you Dmitri owns the visa work and there is still no
+deadline. The page has a **Visas & permits** heading and a milestones table with
+columns Milestone, Owner, Due, Status.
+
+The file names the destination, then carries the row below the rule as a real
+bordered table with its header, so the columns land in the right order and the
+musician can see which cell is which:
+
+| Milestone | Owner | Due | Status |
+| --- | --- | --- | --- |
+| Visa applications for six non-EU players | Dmitri | UNKNOWN | UNKNOWN |
+
+Owner is the only cell they settled. Due is `UNKNOWN` because no date was given
+— pegging it to the Oct 2027 contract date would be inventing one — and Status
+is `UNKNOWN` because "not started" is a reasonable guess and still a guess. The
+page says nothing about any of this until they paste it.
+
+## Boundaries
+
+- Never claim a page was changed. Not "added", not "updated", not "recorded on
+  the page" — it is offered, and it stays offered until they say otherwise.
+- Never track what was pasted or assume an earlier fragment landed. Nothing here
+  remembers, and a page that looks patched is a page you have re-read.
+- Never patch two pages into agreement with each other. Where two records of one
+  event conflict, `policy:divergence` governs, and a cross-reference is the only
+  fragment offered before the fields are settled.
+- Never delete or replace what is on the page as part of a patch. Where a
+  decision contradicts a value already written, say both and let them choose
+  what to do with the old one.

package/agent-pack/AGENTS.md

@@ -1,78 +1,36 @@
 # Artist Operations
 
-One OneNote page is one working unit. Use the Artist Notes MCP tools and the
-playbooks exposed by `list_agent_workflows` and `load_agent_workflow`.
-
-Start with `role:orchestrator`. It selects one useful next action, not a task
-dump. Load the matching project type and only the narrow roles needed to finish
-that action.
-
-Load `policy:intake` first when the musician points at a notebook rather than a
-page, or when the pages are unstructured and no working unit has been agreed.
-Intake surveys, classifies, and proposes templates; it ends as soon as one
-working unit is chosen.
-
-Three policies apply to every answer, whether or not anything loaded them. They
-are policies rather than roles for that reason: a role is a one-line summary
-until something loads it, so a rule that must hold unprompted cannot live in
-one.
-
-
-- `policy:answering` — answer what was asked and keep the machinery out of it.
-  Which tool ran and why is context, not content. Limits, gaps, contradictions
-  and the page behind a fact are always reported, however short the answer.
-- `policy:evidence` — assume the likely shape of a page, verify, and widen when
-  the assumption does not hold. A cheap look that found nothing is not a
-  finding: "no date near the top" is not "no date recorded".
-- `policy:divergence` — when two pages in the notebook may describe one event,
-  name the page every answer came from, never switch silently, and let the
-  musician decide which is the project. Shortlist on resemblance, decide on
-  whether the identifying facts agree.
-
-Load `policy:local-state` before persisting agent-owned working context. Local
-state is optional, disposable, and confined to `.artist/local/`. It is not a
-coordination, claims, review, concurrency, or maintenance system.
-
-The MVP is strictly read-only:
-
-- OneNote is the source of artist and project data, and the only source consulted
-  by default. `list_notes`, `map_notes` and `read_note` are the default data
-  tools: list to find the notebook, map to triage it cheaply, read to decide
-  anything. A sketch from `map_notes` is a page opening, never a summary, so
-  nothing is classified or called complete on one.
-- Drafts, audits, plans, and completion summaries appear only in chat.
-- Never send, book, update, close, or write anything on the user's behalf.
-- Cite page titles for material facts and label inference explicitly.
-- Treat missing data as unknown, never as permission or availability.
-- The Auditor reviews the current draft in chat; the Janitor only proposes
-  cleanup. Neither role creates infrastructure or performs external writes.
-
-## Supporting evidence is opt-in
-
-`policy:evidence` is the authoritative statement of this rule and is loaded on
-every session. What follows restates it for coding agents reading this file
-instead of the briefing. If the two ever disagree, the policy governs.
-
-Gmail, Google Calendar, and email attachments are readable through
-`list_emails`, `read_email`, `map_attachment`, `read_attachment`, `list_events`,
-and `read_event`. They are supporting evidence for a OneNote page and nothing
-else.
-
-- Do not read them unless the musician asks. A connected account is not a
-  standing instruction to search it, and no role may reach for evidence on its
-  own initiative to enrich an answer the page already supports.
-- Ask before the first read. When a page cannot answer something and evidence
-  plausibly could, say what is missing and offer to look — name the source and
-  the search you intend. Wait for a yes.
-- One request grants one look, not a standing licence. A later question starts
-  over unless the musician said to keep using the source.
-- Evidence never becomes the working unit. An email thread or calendar entry
-  corroborates a page; it never replaces it, and it never becomes the thing a
-  playbook operates on.
-- Read one message and one event at a time. Never sweep a mailbox or a date
-  range to see what turns up.
-- Cite evidence separately from the page: name the message subject and date, or
-  the event and its time zone, so a fact from outside OneNote is always visibly
-  from outside OneNote.
-- A missing or unconnected source is unknown, never a negative finding. "No
-  Google connection" is not "no such email exists".
+One OneNote page is one working unit. The rules that govern this work are the
+playbooks in `.artist/`, and they are not summarised here.
+
+Load them before working on the musician's notes:
+
+- With the Artist Notes MCP server connected, call `list_agent_workflows` once
+  per session. Whatever it returns in full is in force from that moment, and
+  `load_agent_workflow` fetches anything it listed as a one-line summary. Start
+  with `role:orchestrator`, which selects one useful next action rather than a
+  task dump, then the matching project type.
+- Without the server, read `.artist/policies/` directly. Every file there
+  applies to this work whether or not anyone loaded it.
+
+The tools are read-only. There is no path here that writes to OneNote, sends a
+message, books anything, or edits a calendar — drafts, plans, audits and page
+patches are handed to the musician, who applies them or does not.
+
+## Why this file says so little
+
+It used to restate the pack: which policies always apply, the evidence
+boundary, how work is handed over. Every one of those drifted. It announced
+three always-loaded policies after there were five, and it kept telling readers
+to let the musician decide which page is the project — phrasing
+`policy:divergence` was rewritten to forbid, still sitting here months later
+contradicting the policy in force.
+
+Nothing could catch that. `registry.json` is derived from `.artist/`, so every
+playbook carries a checksum and this file carries none; it is the one copy of
+these rules that nothing verifies and nothing loads. A restatement here is a
+claim about the pack that no test, no checksum and no session can check.
+
+So this file names where the rules are and stops. If you are tempted to
+summarise a policy here for convenience, that convenience is what drifted — put
+it in the playbook, where the registry can see it.

package/agent-pack/registry.json

@@ -15,7 +15,7 @@
       "name": "Divergence",
       "description": "When two pages in the notebook describe the same event, say so, and let the musician settle each fact the two disagree on. Neither page is the project — the event is, and the pages are two records of it.",
       "file": ".artist/policies/DIVERGENCE.md",
-      "sha256": "fe423f0c661ca40174d71ff4d6e097cb7e873c419c3919e8f79063a77e81bacc"
+      "sha256": "944c4e685740dc1968c44176998759a1949bb3ca43a8a84a19711dde05fcf88f"
     },
     {
       "id": "policy:evidence",
@@ -41,6 +41,14 @@
       "file": ".artist/policies/LOCAL_STATE.md",
       "sha256": "f29aab016151d8f42fabe5f573622bb79b81c292c3601919ed0bfc839bbbe975"
     },
+    {
+      "id": "policy:patch",
+      "kind": "policy",
+      "name": "Patch",
+      "description": "Once the musician has decided something, hand them the smallest fragment that records it, and say which part of the page it goes under. They paste it. The page is unchanged until they do, and nothing here can change it — so a patch is written as something to paste, never as something that has happened.",
+      "file": ".artist/policies/PATCH.md",
+      "sha256": "b5da16f37d6210d93d323e181c08cf98b0bf4f3a0d9b77518bdf343296122b9f"
+    },
     {
       "id": "project-type:concert",
       "kind": "project-type",

package/dist/agents.js

@@ -222,7 +222,6 @@ const installAgentPack = async (directory = process.cwd()) => {
     for (const file of packFiles) {
         const destination = resolve(destinationRoot, file);
         if (file === 'AGENTS.md' && agentsInstructionsSkipped) {
-            console.log('Left existing AGENTS.md unchanged');
             continue;
         }
         await mkdir(dirname(destination), { recursive: true });
@@ -234,8 +233,20 @@ const installAgentPack = async (directory = process.cwd()) => {
             console.log(`Already current ${file}`);
         }
     }
+    // The skip is right — this file is the user's to edit, and nothing here can
+    // tell a deliberate edit from a copy that simply predates the current one.
+    // But the two read identically at the terminal, and they need different
+    // actions: one is finished, the other is a user still holding rules that have
+    // since been rewritten. So say what the shipped file now contains and how to
+    // take it, rather than only that theirs was kept.
     if (agentsInstructionsSkipped) {
-        console.log('Reference the files under .artist/ from your existing AGENTS.md.');
+        console.log('Left existing AGENTS.md unchanged — it differs from the shipped one, ' +
+            'which this cannot tell from an edit of yours.');
+        console.log('The shipped AGENTS.md no longer restates any rules: it points at ' +
+            '.artist/ and list_agent_workflows, because every summary it used to ' +
+            'carry drifted from the playbooks. If yours still summarises policies, ' +
+            'it may be describing rules that have changed.');
+        console.log('To take the shipped version, delete AGENTS.md and run this again.');
     }
     console.log('Read-only artist workflow pack is ready.');
 };

package/dist/server.js

@@ -102,7 +102,7 @@ const selectNotebook = async (notebook, tool) => {
         : null;
     return { pages, scope };
 };
-const serverVersion = '1.2.0'; // x-release-please-version
+const serverVersion = '1.2.1-staging.59'; // x-release-please-version
 const errorResult = (err) => {
     const message = err instanceof GraphError ? err.message : `Unexpected error: ${err}`;
     return { content: [{ type: "text", text: message }], isError: true };
@@ -131,12 +131,20 @@ const renderWorkflowBriefing = async (entries, load) => {
     // nobody asks whether two pages are one event, and the damage is done by
     // working in one of them as though the other were not there.
     //
+    // Patch binds at the moment a recommendation is agreed, which is the end of
+    // an ordinary answer and not a moment anything reaches for a policy. Left as
+    // a summary it would be read after the fragment had already been handed over
+    // — restating the whole page, inventing the date nobody gave, or written as
+    // though the page had been updated. Divergence and answering both delegate to
+    // it by name, so summarising it breaks two policies that are loaded in full.
+    //
     // Local state stays a summary. It answers a question that is asked out loud.
     const ALWAYS = [
         "policy:intake",
         "policy:answering",
         "policy:evidence",
         "policy:divergence",
+        "policy:patch",
     ];
     const alwaysInFull = (entry) => entry.kind === "project-type" || ALWAYS.includes(entry.id);
     const upfront = entries.filter(alwaysInFull);
@@ -215,11 +223,34 @@ const runServer = async () => {
     // refusing to start would leave Claude Desktop reporting a broken server
     // rather than an account that needs connecting, which is a much worse
     // sentence to act on. stderr, not stdout — stdout is the protocol channel.
-    const server = new McpServer({ name: "artist-notes", version: serverVersion });
+    // Without this the pack is inert on a client that has no repository to read
+    // `AGENTS.md` from — which is Claude Desktop, the surface `init` configures.
+    // `list_agent_workflows` is a tool like any other, so nothing calls it unless
+    // something says to, and a session then answers from the tool descriptions
+    // alone with no policy in force. That is the "a rule in a role is not in
+    // force" failure one level up: the briefing was correct and never arrived.
+    //
+    // It deliberately carries no rules of its own. `AGENTS.md` restated the pack
+    // for repository clients and drifted from it — it still announces three
+    // always-loaded policies, and still uses the winner-picking phrasing that
+    // `policy:divergence` was edited to forbid. A third copy would drift too, so
+    // this says only where the rules are and that they bind, and the briefing
+    // stays the single statement of what they are.
+    const instructions = "Call `list_agent_workflows` before answering anything about the user's " +
+        "notes, once per session. It returns the workflow playbooks that govern " +
+        "this server, and whatever comes back in full is in force from that moment " +
+        "— it is not reference material to consult if a question seems to call for " +
+        "it. Working from these tool descriptions alone means working with no " +
+        "policy in force, which is not a lighter version of this server's " +
+        "behaviour but a different one. If a call fails or the briefing reports a " +
+        "playbook it could not read, say so before answering.";
+    const server = new McpServer({ name: "artist-notes", version: serverVersion }, { instructions });
     server.tool("list_agent_workflows", "List the read-only artist roles, project types, and policies available " +
-        "at runtime. The project-type playbooks and the intake policy are " +
-        "returned in full and are in force as returned — they govern the survey, " +
-        "the classification and any templates, and are not optional reading. " +
+        "at runtime. Whatever comes back in full is in force as returned and is " +
+        "not optional reading — the project-type playbooks and several policies " +
+        "arrive that way, governing the survey, the classification, what is " +
+        "stated and how firmly, and how anything is handed over for pasting. " +
+        "Anything listed as a one-line summary is not in force until loaded. " +
         "Load the Orchestrator before handling a project.", {}, async () => {
         try {
             const text = await renderWorkflowBriefing(await listAgentWorkflows(), loadAgentWorkflow);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@manudota/artist-mcp",
-  "version": "1.2.0",
+  "version": "1.2.1-staging.59",
   "description": "MCP server that reads your OneNote notes, with optional Gmail and Calendar as supporting evidence, via a hosted connection.",
   "repository": {
     "type": "git",