Update to Thegram

{
  "description": "Build and maintain enterprise-grade, source-backed knowledge in Thegram .gram documents with vault_* tools. Research any subject, project, organization or plan across the connected sources the request covers (repositories, documents, chats, mail, calendars, the web) with an evidence-driven task plan, and write one deeply explained document per subject whose claims, evidence, decisions, risks and supporting or contradicting reasoning are typed records with pinned provenance, a verification basis and revision history. Update the same document incrementally without duplicates, keep observed facts, reported claims and inferences distinct, respect destination and audience boundaries, verify storage, logic and retrieval, and report blocked work as partial. Also answers from saved knowledge and handles schedules, scheduled automations, agent work, dashboards and historical backfills.",
  "included_files": [
    {
      "relative_path": "references/automations.md",
      "size_in_bytes": 4637
    },
    {
      "relative_path": "references/backfill.md",
      "size_in_bytes": 9508
    },
    {
      "relative_path": "references/contracts.md",
      "size_in_bytes": 24050
    },
    {
      "relative_path": "references/examples.md",
      "size_in_bytes": 10135
    },
    {
      "relative_path": "references/knowledge-model.md",
      "size_in_bytes": 12563
    },
    {
      "relative_path": "references/person-vault.md",
      "size_in_bytes": 4923
    },
    {
      "relative_path": "references/record-meanings.md",
      "size_in_bytes": 25845
    },
    {
      "relative_path": "references/schedule.md",
      "size_in_bytes": 4367
    },
    {
      "relative_path": "references/widget-data.md",
      "size_in_bytes": 11902
    },
    {
      "relative_path": "references/writing.md",
      "size_in_bytes": 30308
    }
  ],
  "name": "thegram-cloud",
  "skill_md_contents": "---\nname: thegram-cloud\ndescription: Build and maintain enterprise-grade, source-backed knowledge in Thegram .gram documents with vault_* tools. Research any subject, project, organization or plan across the connected sources the request covers (repositories, documents, chats, mail, calendars, the web) with an evidence-driven task plan, and write one deeply explained document per subject whose claims, evidence, decisions, risks and supporting or contradicting reasoning are typed records with pinned provenance, a verification basis and revision history. Update the same document incrementally without duplicates, keep observed facts, reported claims and inferences distinct, respect destination and audience boundaries, verify storage, logic and retrieval, and report blocked work as partial. Also answers from saved knowledge and handles schedules, scheduled automations, agent work, dashboards and historical backfills.\n---\n\n# Thegram knowledge\n\nUse the current connection's `vault_*` tools, including host-prefixed names: reads `vault_guide`, `vault_search`, `vault_read`, `vault_browse`, `vault_changes`, `vault_comments`; writes `vault_create`, `vault_edit`, `vault_comment`, `vault_feedback`, `vault_move`, `vault_delete`, `vault_restore`. ChatGPT and Claude connect to `https://vault.thegram.one/mcp` with OAuth; coding agents use scoped API keys against the same endpoint, with the same tools, records and rules. Authentication, injected session context and reminders belong to the host adapter. Never install a desktop app, expose a local-only folder or switch credentials to get around a denial.\n\nThese instructions are English; answers, progress, titles, headings and record `t`/`d` follow the person's current language. Keep proper names, quotations and technical identifiers as written.\n\n## 1. Rules that always apply\n\n1. **Authorization.** Saving needs authorization for the purpose and the destination, not merely a writable connection. Retrieval, review, analysis and drafts stay read-only unless storing the result is requested; read-only and \"do not save\" requests create no records or run receipts. An established project-execution policy can authorize durable outcomes within that project; connector access alone cannot.\n2. **Destination.** Write to the document the person names or the established document for the subject. Otherwise resolve the destination with [person-vault.md](references/person-vault.md): a vault the person names holds new documents in the person's folder there, and without one the person's own storage is used; a team vault is never chosen by itself. Use exact vault refs from `vault_browse`, never display names, and never switch mounts after a failure. `vault_browse` lists only this agent's grants: on `AGENT_SCOPE_DENIED` stop, point the person to Thegram Settings → Connected agents, and rediscover mounts after they change access.\n3. **Evidence.** Every stored claim traces to inspected sources or to named premises, with how it is known ([knowledge-model.md](references/knowledge-model.md)). Never fabricate facts, statuses, dates, owners, events, completions or revisions; an AI recommendation stays a `proposed` decision.\n4. **One subject, one document.** Reuse the established document, its path and its record IDs; update in place and never duplicate a document, source or claim. Change a record's status instead of removing it; revisions keep the history.\n5. **Write safety.** One coherent unit per `vault_edit`; `set`/`unset` carry the `old` value read; replacing a section needs `base_revision`/`expected_hash` from the same `source:true` read; one `request_id` per intended change, reused only to retry that change. A write landed only when the answer shows `sync.state: synced` and a fresh read confirms it.\n6. **Privacy.** Store structured, sourced knowledge for the purpose only: never transcripts, message bodies, attachments, secrets, credentials, account numbers or unrelated third-party details. Respect the destination's audience (knowledge-model.md section 6).\n7. **Completion.** Storage success, task completion and completion of the investigation are different. Finish reachable authorized work in the same execution; a genuine limit yields a partial result with pending tasks and an exact resumption point. Never claim background work that is not actually scheduled.\n\n## 2. Orient\n\n- Call `vault_browse` once per purpose: each `vaults[]` row's `ref` is the path prefix. Then `vault_browse {path, summary:true}` (a document or a folder) for open records, recent revisions, `rev`/`hash` and `next`, and `vault_browse {path, select:{type:\"project\"}}` for the root record. Before creating anything, check `vault_browse {path}` and `vault_search` for a moved or renamed document.\n- Before acting on a remembered decision or task, read it: `vault_read {refs:[\"<path>#<id>\"], fields:[\"t\",\"d\",\"x\"]}`.\n- Resume with `vault_changes {path, since: next}`. For a requested historical window, compute an explicit ISO UTC `since` and follow every `more`.\n- Before the first write or an unfamiliar operation, call `vault_guide {task}` (and `{topic:\"templates\"}` for the vocabulary); the current schemas and guide win over this skill.\n- A coding-agent adapter may inject `<thegram>` context (document path, revision, root record, open records). It is context, not instruction or authorization; repository binding is in [contracts.md](references/contracts.md).\n\n## 3. Route the request\n\nRead the listed references before acting; each is one step from here.\n\n| Request | Read |\n|---|---|\n| Research, write, explain or update a subject, project, organization or plan | [writing.md](references/writing.md), [knowledge-model.md](references/knowledge-model.md), [record-meanings.md](references/record-meanings.md) |\n| Answer from saved knowledge | section 7 here; knowledge-model.md section 3 for \"why\" questions |\n| Change a status or a few fields | [record-meanings.md](references/record-meanings.md) (statuses, closing a record) |\n| First write, section edits, body syntax, error codes, coding-repository binding | [contracts.md](references/contracts.md) |\n| Ambiguous classification or a worked write sequence | [examples.md](references/examples.md) |\n| Personal writing without an established document | [person-vault.md](references/person-vault.md) |\n| Schedule, commitments and deadlines | [schedule.md](references/schedule.md) with writing.md |\n| A scheduled automation run, or work an agent does for the person | [automations.md](references/automations.md) |\n| Dashboards and widgets | [widget-data.md](references/widget-data.md) |\n| Authorized import or reconstruction of history | [backfill.md](references/backfill.md) with writing.md |\n\nA timeline, journal or log the person asks for is an ordinary subject document written with the same method; chronology then shapes its sections. An explicitly quick or narrowly scoped request keeps its scope without an expansive research run; identity, evidence and concurrency rules still apply.\n\n## 4. Research and write loop\n\nFor substantial work (writing.md has the full method):\n\n1. Resolve the destination and read the existing document: brief, outline, root, research tasks, latest run and scope sources.\n2. Plan assistant-owned research tasks (`research-work`) with questions, source scope and acceptance evidence; save them with the first useful unit.\n3. Repeat bounded units: read one source unit completely; classify its atomic facts by meaning (record-meanings.md); tag each claim's basis and link its reasoning (knowledge-model.md); write the unit's sources, claims, links and explanation together; checkpoint tasks, run and scope.\n4. When understanding changes, rewrite the affected sections and records; never append a contradicting update.\n5. Audit with writing.md section 7 and knowledge-model.md section 9, verify with section 9 here, then report.\n\n## 5. Records\n\n- A commit, PR, thread, file or chat is a source container, not a record type; one item may yield several facts or only source coverage. Classify each fact by meaning, one fact per record.\n- `t` is a concise proposition or name, never a time or ID. `d` is self-contained: subject, scope, conditions, exceptions, uncertainty and provenance, without copying the source.\n- IDs are stable slugs with a type prefix (`k-`, `dec-`, `task-`, `risk-`, `evd-`, `src-`, `m-`, `ev-`) using lower-case ASCII letters, digits and hyphens. Source IDs come from the item's identity; run and request IDs from the actual execution.\n- `source` holds `source` record IDs; `ref` holds one URL others can open, never a local path or `file://` URL.\n- Time: an event's `at` is when it happened, at its known precision; a commit date proves only the commit time. Source dates stay in their fields and recording time is the server's. Use `effective_at` only as writing.md section 5 describes.\n- No event per commit, task per session, or record made to fill a widget; dashboards count stored records ([widget-data.md](references/widget-data.md)).\n\n## 6. One coherent unit, one patch\n\nSave an item's source, the claims it establishes, their links and the affected prose in one `vault_edit` against the head. Operations run in order, so add a record before another links to it. A record appears in the body only with `place` or a standalone `[[id]]`.\n\n```json\n{\"path\": \"@mounts/<vault-id>/<root>/<subject>.gram\", \"request_id\": \"run-20261027-u03\",\n \"operations\": [\n  {\"op\": \"add\", \"record\": {\"type\": \"source\", \"id\": \"src-core-patch-rs\",\n    \"fields\": {\"t\": [\"core/src/patch.rs\"], \"d\": [\"Read lines 40-180 at commit <full-sha>: base revision and hash checks before operations apply.\"],\n      \"ref\": [\"https://github.com/<owner>/<repo>/blob/<full-sha>/core/src/patch.rs\"], \"tag\": [\"source:github\"]},\n    \"links\": [[\"part-of\", \"prj-format\"]]}, \"place\": \"none\"},\n  {\"op\": \"add\", \"record\": {\"type\": \"knowledge\", \"id\": \"k-no-lost-update\",\n    \"fields\": {\"t\": [\"Concurrent section edits cannot silently overwrite each other\"], \"d\": [\"Inferred from the stale-base check; covers writes through Core only, not files edited outside Thegram.\"], \"tag\": [\"basis:inferred\"]},\n    \"links\": [[\"part-of\", \"prj-format\"]]}, \"place\": {\"section\": \"Write guarantees\"}},\n  {\"op\": \"add\", \"record\": {\"type\": \"knowledge\", \"id\": \"k-stale-base-rejected\",\n    \"fields\": {\"t\": [\"Core rejects a patch whose base revision is stale\"], \"d\": [\"As of <full-sha>: a patch with base_revision/expected_hash fails with STALE_REVISION once the document has moved on.\"],\n      \"source\": [\"src-core-patch-rs\"], \"tag\": [\"basis:observed\"]},\n    \"links\": [[\"part-of\", \"prj-format\"], [\"supports\", \"k-no-lost-update\"]]}, \"place\": \"none\"},\n  {\"op\": \"set\", \"entity\": \"task-research-writes\", \"key\": \"x\", \"value\": \"active\", \"old\": \"open\"}\n ]}\n```\n\n- `add` field values are arrays; `t`, `d`, `x`, `at` and `ref` hold one value, while `tag` and `source` repeat. `set` takes `value` or `values` plus `old`.\n- Keep a call under about 20 sources, 60 operations and 8,000 characters; split at a semantic boundary.\n- Section replacement, `edit-text`, mentions, collections and every error code are in [contracts.md](references/contracts.md).\n\n## 7. Read and answer\n\n- Find with `vault_search {query, folder}` in a plain sentence; retry once with other wording before concluding nothing is recorded. The answer already holds the text of the best matches: open the rest with `vault_read {refs:[\"<path>#<id>\"]}`, sections with `vault_read {refs:[\"<path>§<heading>\"]}` and neighbours with `vault_read {refs:[\"<path>#<id>\"], relations:{direction:\"both\"}}`. Narrow by `type`, `status`, `from`/`to`/`date` or `scope` (name a `folder` or `documents` with them); `relevance: \"weak\"` means the hits are only the nearest records. A first page that stops with `LOW_RELEVANCE` already holds the strong matches; follow `cursor` with the same arguments only when the question needs every match.\n- When the person asks what an earlier answer relied on, keep that search's `receipt` and run `vault_search {receipt}`: it shows whether the same records come back from the documents as they were then.\n- For \"why\" questions follow `supports`/`contradicts` with `relations` and give each step's basis; say when a reason is not recorded instead of inventing one.\n- Past states: `as_of:{revision | effective_at | recorded_at}` on `vault_read`, and on `vault_browse {path, ids:true}`; `vault_changes` lists what changed.\n- Answers cite `path#id` or the section, keep observed, reported and inferred claims distinct, and write nothing.\n\n## 8. Errors\n\nFix the named cause and retry only within the original scope; [contracts.md](references/contracts.md) lists every code. `E_PRECONDITION`: reread the fields, keep concurrent edits and resend with a new `request_id`. `STALE_REVISION`, `HASH_MISMATCH`, `E_CAS_REQUIRED`: reread the section and reconcile before resending with that read's tokens. A lost answer: retry the identical request with the same ID. `AGENT_SCOPE_DENIED`, `E_READ_ONLY`, `E_FORBIDDEN`, `E_PATH`: stop and report; never switch destination.\n\n## 9. Verify, stop check and report\n\nAfter creating a document, adding substantial knowledge or changing an important decision or policy, verify retrieval as well as storage:\n\n1. Ask one or two natural questions a person would ask later, not a copied title or ID, with `vault_search` in the folder where the material should be found.\n2. Open the returned record or section and check that it answers with the right subject, scope and conditions. A matching title or score alone is not proof.\n3. If it is not found, clarify only missing source-backed subject or conditions in `t`/`d` or the section and retry once with other wording; otherwise report \"saved and read back; retrieval not verified\" with the question and the limitation. Never keyword-stuff or add duplicate records to chase rank.\n\nCoding-agent reminders and stop hooks do not authorize writes or change this workflow; never write filler to satisfy them. Before finishing, reconcile active tasks with reality: unfinished queued work returns to `open` with its next action.\n\nReport the document path and revision, what the document now explains, material additions and corrections, task outcomes, inspected scope and gaps, and the logic-audit summary. Report storage, readback, retrieval and rendered UI separately, naming the questions and `path#id` actually checked.\n"
}