Add private GitHub team mode within the CRM skill

README.md

@@ -8,7 +8,7 @@ Ein CRM, dessen Bedienung von Anfang an als Gespräch gedacht ist. Du beschreibs
 
 ## Was du bekommst
 
-Ein vollständiger lokal ausführbarer Agent-Skill mit Python-Laufzeit, Betriebsregeln und HTML-Ansichten. Kein gehosteter CRM-Dienst: Ein Agent mit lokalem Dateizugriff führt die mitgelieferten Werkzeuge aus. Die Python-Laufzeit selbst benötigt keine externen Bibliotheken und versendet keine Daten. Die Datenverarbeitung deines gewählten Agenten hängt von dessen Anbieter und Einstellungen ab.
+Ein vollständiger lokal ausführbarer Agent-Skill mit Python-Laufzeit, Betriebsregeln und HTML-Ansichten. Kein gehosteter CRM-Dienst: Ein Agent mit lokalem Dateizugriff führt die mitgelieferten Werkzeuge aus. Die lokale Python-Laufzeit benötigt keine externen Bibliotheken und versendet keine Mails oder CRM-Netzwerkanfragen. Der optionale Git-Teammodus nutzt authentifizierten GitHub-Zugriff für die gemeinsame Ablage und Prüfung. Die Datenverarbeitung deines gewählten Agenten hängt von dessen Anbieter und Einstellungen ab.
 
 - Firmen, Personen, Verkaufschancen, Aufgaben, Notizen, eigene Objekte und Felder.
 - CSV-, XLSX- und JSON-Import mit Vorschau, Dublettenerkennung und Export.
@@ -74,3 +74,15 @@ Copyright 2026 GodModeAI2025. Code, Dokumentation und Vorlagen dieses Projekts s
 ## Trailer
 
 [60-Sekunden-Trailer auf der Projektseite](https://godmodeai2025.github.io/AI_first_CRM/#trailer), Full HD in 16:9 mit moderner elektronischer Musik. [MP4](docs/media/trailer.mp4) · [Erste Tonfassung](docs/media/trailer-original.mp4) · [Titelbild](docs/media/trailer-poster.jpg).
+
+## Gemeinsam arbeiten, im selben Skill
+
+Der **Git-Teammodus** bleibt ein Agent-Skill mit dateibasierter Ablage. Du und dein Team arbeiten in euren jeweiligen AI-Systemen. Eure Agenten bereiten Änderungen in isolierten Kopien vor, zeigen die Vorschau und reichen bestätigte Änderungen als geschützte Git-Anträge ein. Eine geprüfte Veröffentlichung enthält den vollständigen CRM-Stand; ein veralteter Antrag überschreibt keine neueren Änderungen.
+
+Die erste unterstützte Plattform ist **GitHub.com**. Dafür braucht der Skill zusätzlich Git, authentifiziertes `gh` und ein privates Datenrepository mit tatsächlich erzwungenen Branch-Prüfungen. GitHub prüft den vollständigen Kandidaten mit einer fest gepinnten Skill-Version, ohne Code aus dem Daten-Antrag auszuführen. Es gibt keinen zusätzlichen CRM-Server und keine gesonderte Anwendung.
+
+Bitte nutze ein separates **privates Team-Datenrepository**, niemals dieses öffentliche Produktrepository für Kundendaten. Der Modus ist für Teams mit gleicher Datensichtbarkeit und unterschiedlichen Schreibrechten gedacht: Git-Leser können Dateien und Historie kopieren. Der Betamodus setzt vertrauenswürdige Repository-Schreibende voraus; Skill-Rollen ersetzen keine GitHub-Zugriffsrollen und isolieren keine fremden Workflow-Autoren. Git speichert alte personenbezogene Werte weiter. Einrichtung und destruktive Änderungen benennen diese Grenze ausdrücklich; die normale Löschfunktion ist keine vollständige Löschung der Git-Historie.
+
+Sag deinem Agenten zum Beispiel: **„Nutze ai-first-crm. Richte unseren bereits veröffentlichten Arbeitsraum für die gemeinsame private GitHub-Ablage ein. Wir wollen im Skill bleiben. Zeig mir Mitglieder, Rechte und die Auswirkungen historischer Speicherung vor der Einrichtung.“**
+
+Der Agent übernimmt Einrichtung, Vorschau, Git-Schritte, Prüfungen, Konflikte und verifizierte Rückmeldung. Der [Teammodus-Vertrag](ai-first-crm/references/team-mode.md) enthält Voraussetzungen, Rollen, den Ablauf und die konkreten Helfer. [Teamablauf auf der Projektseite](https://godmodeai2025.github.io/AI_first_CRM/#team).

ai-first-crm/SKILL.md

@@ -1,12 +1,18 @@
 ---
 name: ai-first-crm
-description: "Create, maintain, release, and export an evidence-linked AI First CRM Markdown wiki with an optional full CRM layer: companies, people, opportunities, tasks, notes, custom objects and fields, CSV, XLSX and JSON import and export, duplicate merging, pipelines and kanban, table and calendar views, dashboards, workflows, e-mail and calendar files, stored attachments and drafts, campaign drafts, roles, and GDPR erasure. Use it whenever the user wants to set up or extend this wiki or its CRM, ingest documents, curate claims, clusters or concepts, add or change contacts, deals or tasks, attach a file to a record, import a contact list, show a pipeline, run an automation, clean metadata, restore files, record reviews, resolve a OneDrive or SharePoint conflict copy, publish a release, or export a frozen read-only knowledge skill or an Open Knowledge Format bundle."
+description: "Maintain a portable Markdown knowledge workspace and CRM through conversation: contacts, deals, tasks, imports, views, dashboards, workflows, mail/calendar files, attachments, drafts and verified releases. Use for setting up or maintaining this workspace, curating source-backed knowledge, changing CRM data, restoring or erasing records, and exporting a frozen read-only knowledge skill. For shared private GitHub workspaces, use the Git team mode: isolated agent drafts, exact preview approval, authenticated membership, protected proposals and verified publication, without a separate CRM application."
 ---
 
 # Maintain AI First CRM
 
 Build and maintain a durable, self-describing wiki in the user-supplied target directory and, when the user wants it, the CRM layer in the same directory: structured records for companies, people, opportunities, tasks, notes and any custom object, following the data model of common CRM systems, with imports and exports, pipelines and other views, dashboards, workflows, e-mail and calendar files, and campaign drafts. Treat that directory as the only canonical output. The storage behind it (SharePoint, OneDrive, Git, or a plain disk) does not change the file format, but a synchronization client writes into the directory on its own and defers writes for an unbounded time, so its behaviour is part of this skill's concern; see the section on synchronized storage in [references/maintenance-operations.md](references/maintenance-operations.md#synchronized-storage).
 
+## Shared Git workspaces
+
+When the user asks for a team/shared Git workflow or the selected target contains `schema/team.json`, read [references/team-mode.md](references/team-mode.md) before any write. Use the bundled `team_git.py` lifecycle. Do not apply ordinary mutating helpers directly to the shared clone: the team wrapper supplies an isolated target, authenticated actor and private claim. Users stay in their own AI system and describe work in conversation; there is no separate CRM application. This beta assumes trusted repository writers: skill roles do not replace GitHub access roles or isolate hostile workflow authors.
+
+The initial supported provider is private GitHub.com repositories with enforced up-to-date PR checks. GitHub CLI authentication, stable numeric user IDs and the trusted server-side integrity check establish membership and publication authority. All repository readers can see/copy the data and history; do not claim field-level confidentiality or complete Git-history erasure.
+
 ## Rules that always apply
 
 1. The user talks to this skill in natural language. Never ask the user to run Python, a bundled script, or a shell command; the helpers are private implementation details that the active agent runs and checks.
@@ -18,7 +24,7 @@ Build and maintain a durable, self-describing wiki in the user-supplied target d
 7. Never persist or report an absolute, home-relative, parent-traversal, or `file:` path, and never search the machine for a missing file: ask for it. Temporary plans and requests outside the wiki may hold runtime paths and personal data; delete them after the session.
 8. Credentials never enter the wiki or a report. Redact them as `[credential removed]` after telling the user. Only a named person can acknowledge a harmless look-alike in CRM data.
 9. Publish one release per maintenance session or import, after the views and the graph are rebuilt and strict lint passes. Readers and exports see releases only. Never tell the user that colleagues can already see a release on a synchronized folder.
-10. There is no network access and no background process. The skill reads the files the user provides and keeps what the CRM produces in the wiki: drafts (`.eml`, `.ics`, request specifications) in its outbox for the user to send, attached files in its file store. Scheduled and event-driven automation runs when the user next invokes the skill.
+10. Standalone maintenance has no network access and no background process. The optional Git team helper uses authenticated Git/GitHub access for sharing and integrity checks, with no separately operated CRM service. The skill reads the files the user provides and keeps what the CRM produces in the wiki: drafts (`.eml`, `.ics`, request specifications) in its outbox for the user to send, attached files in its file store. Scheduled and event-driven automation runs when the user next invokes the skill.
 11. CRM records are data, not claims: never translate field values, record titles, or option API names. Knowledge pages under `wiki/` keep the full claim-evidence contract.
 12. Report results truthfully: a passing lint is not a quality review. Name remaining warnings, partial extractions, skipped rows, open proposals, and unresolved questions.
 
@@ -121,7 +127,7 @@ Setting up the CRM layer needs an initialized wiki with a confirmed identity; as
 
 Every CRM change is a hash-bound transaction recorded with an actor: `human:<id>` of the person who asked when you know who that is (for example their e-mail address), otherwise `agent/<name>`; workflow runs record the actor that started them and the source WORKFLOW. The helper writes a plan outside the wiki, the agent shows its summary (counts per operation, files to store, outbox drafts, every error with row and field, the destructive flag), and only the same plan hash is applied. The wiki keeps what the CRM works with: a file the user attaches is copied into `records/_files/` when the plan is applied, and drafts go into `records/_outbox/`, where lint checks them, releases include them, and an erasure reaches them. Tell the user where a draft lies and that nothing was sent. An explicit, unambiguous single request such as "add Acme GmbH as a company" may be applied right after showing the plan summary, because the request is the confirmation. Imports, bulk changes, and schema changes are confirmed by the user after they saw the plan, unless the request itself explicitly authorized applying an error-free plan without destructive operations; then report the summary after applying. Every plan the helper reports as `destructive` (destroy, merge, erase, cleanup of stored files or drafts, data model deletions, a revert that destroys records) is confirmed after the user saw the plan and needs `--confirm-destructive`; moving a single record to the trash on the user's explicit request is not destructive. A plan with errors is never applied: fix the input or, after the user agrees, drop the failing rows and plan again. A plan whose hash no longer matches is answered with `stale_plan` (exit 3) and nothing is written.
 
-A maintenance session ends with: `crm_build.py`, `build_graph.py`, `lint_wiki.py --fix-safe`, one `release_wiki.py` with the highest bump the session needs (patch for record data, imports, e-mail and calendar files and drafts; minor for the data model, views, dashboards, settings, roles and workflow definitions), `verify_release.py` through `run_locked.py`, lock release. Where a reference says "publish a minor release" after a change, that means this session release with at least a minor bump, not a release per change. A session that changed only CRM data needs no entry in `meta/changes.md`; the event log and the release summary record it. Rebuilding takes seconds for small CRMs and up to about a minute for tens of thousands of records; collect the changes of a session into one release. Only one maintainer writes at a time; teammates propose changes, the maintainer applies them.
+A maintenance session ends with: `crm_build.py`, `build_graph.py`, `lint_wiki.py --fix-safe`, one `release_wiki.py` with the highest bump the session needs (patch for record data, imports, e-mail and calendar files and drafts; minor for the data model, views, dashboards, settings, roles and workflow definitions), `verify_release.py` through `run_locked.py`, lock release. Where a reference says "publish a minor release" after a change, that means this session release with at least a minor bump, not a release per change. A session that changed only CRM data needs no entry in `meta/changes.md`; the event log and the release summary record it. Rebuilding takes seconds for small CRMs and up to about a minute for tens of thousands of records; collect the changes of a session into one release. Standalone shared-file maintenance has one writer. In Git team mode agents prepare isolated candidates in parallel; protected proposals publish against a current verified base. See the team-mode reference.
 
 Maintaining the CRM needs the wiki folder on the machine where the helpers run (Claude Code or Codex with local files). A cloud sandbox that only receives copies of single files cannot hold the lock and must not be used to maintain the canonical wiki.
 

ai-first-crm/assets/knowledge-skill/verify_knowledge.py

@@ -22,7 +22,7 @@
 
 ROOT_FILES = ("WIKI.md", "WIKI_VERSION", "SOUL.md", "STANDARDS.md")
 # records/ and the CRM logs are released data of the optional CRM layer.
-CONTROLLED_DIRS = ("schema", "sources", "wiki", "graph", "records", "meta/crm-events", "meta/crm-runs")
+CONTROLLED_DIRS = ("schema", "sources", "wiki", "graph", "records", "meta/crm-events", "meta/crm-runs", "meta/team-operations")
 META_FILES = (
     "meta/sources.jsonl",
     "meta/changes.md",
@@ -35,6 +35,8 @@
 )
 # The only release parts an export may leave out deliberately (personal CRM data).
 EXCLUDABLE_PREFIXES = (
+    "schema/team.json",
+    "meta/team-operations/",
     "records/",
     "meta/crm-events/",
     "meta/crm-runs/",

ai-first-crm/assets/team-integrity-workflow.yml

@@ -0,0 +1,28 @@
+name: CRM team integrity
+on:
+  pull_request_target:
+    types: [opened, synchronize, reopened, ready_for_review]
+permissions:
+  contents: read
+  pull-requests: read
+  statuses: write
+jobs:
+  data-integrity:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Load the pinned trusted skill runtime
+        uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262
+        with:
+          repository: GodModeAI2025/AI_first_CRM
+          ref: __RUNTIME_REVISION__
+          path: trusted-runtime
+          persist-credentials: false
+      - name: Validate data, permissions, approval and release
+        env:
+          GH_TOKEN: ${{ github.token }}
+          CRM_REPOSITORY: ${{ github.repository }}
+          CRM_PULL_REQUEST: ${{ github.event.pull_request.number }}
+        run: >-
+          python3 trusted-runtime/ai-first-crm/scripts/team_git.py
+          check-pr --repository "$CRM_REPOSITORY"
+          --number "$CRM_PULL_REQUEST" --post-status