Route Git mutations through ObjectType contracts

.github/workflows/ci.yml

@@ -0,0 +1,38 @@
+name: CI
+
+on:
+  push:
+  pull_request:
+
+jobs:
+  validate:
+    runs-on: windows-latest
+    steps:
+      - name: Check out plugin
+        uses: actions/checkout@v4
+        with:
+          path: godmode-plugin-git
+      - name: Check out current GodMode API
+        uses: actions/checkout@v4
+        with:
+          repository: ReBoticsAI/GodMode
+          ref: 732d993808d641645ed706d8560719cba5349d6f
+          path: GodMode
+      - name: Set up Node
+        uses: actions/setup-node@v4
+        with:
+          node-version: 22
+          cache: npm
+          cache-dependency-path: godmode-plugin-git/package-lock.json
+      - name: Install GodMode workspace
+        run: npm ci
+        working-directory: GodMode
+      - name: Build current plugin API
+        run: npm run build -w @godmode/kernel && npm run build -w @godmode/plugin-api
+        working-directory: GodMode
+      - name: Install
+        run: npm ci
+        working-directory: godmode-plugin-git
+      - name: Validate
+        run: npm run validate
+        working-directory: godmode-plugin-git

README.md

@@ -5,29 +5,67 @@ Official marketplace plugin: structured **git** tools for Intelligence over the
 ## Requirements
 
 - `git` on the host PATH
+- GodMode kernel client API version 1. The plugin rejects a mismatched host before
+  registering its ObjectType or tools.
 - Working directory must be a git checkout (local GodMode / operator workspace). Hub tenant sandboxes only work if they are real clones with remotes.
 
+## Kernel model
+
+The plugin registers an adapter-backed `GitRepository` ObjectType with one
+tenant-local record:
+
+- ObjectType: `GitRepository`
+- record ID: `coding-root`
+- operations: `list`, `get`
+- record actions: `branch`, `add`, `commit`, `push`, `fetch`, `pull`
+
+The generic HTTP form of those actions is:
+
+`POST /api/records/GitRepository/coding-root/actions/:action`
+
+The JSON request body is the action input itself. HTTP clients send
+`X-Kernel-Confirmation` when satisfying a confirmation challenge. The plugin's
+compatibility tools do not make that HTTP request: they call the versioned
+in-process `api.kernel.runAction(...)` client against the same record action.
+
 ## Tools
 
 | Tool | Mode | Purpose |
 |------|------|---------|
 | `git_status` | auto | Branch + porcelain status |
-| `git_diff` | auto | Staged / unstaged / range (size-capped) |
-| `git_log` | auto | Recent commits |
-| `git_branches` | auto | List branches |
-| `git_checkout` | confirm | Create (`create=true`) and/or checkout a branch |
+| `git_diff` | auto | Unstaged, staged, triple-dot revision-range, or path-limited diff |
+| `git_log` | auto | Up to 50 recent commits |
+| `git_branches` | auto | List local branches and upstream details |
+| `git_branch` | confirm | Check out a branch, creating it when `create=true` |
 | `git_add` | confirm | Stage pathspecs |
-| `git_commit` | confirm | Commit staged changes (no force amend in v1) |
-| `git_push` | confirm | Push current branch (no `--force`) |
-| `git_fetch` | auto | Fetch remotes |
-| `git_pull` | confirm | Pull with ff-only by default |
+| `git_commit` | confirm | Commit staged changes; hooks run unless `skipHooks=true` |
+| `git_push` | confirm | Push `HEAD` to the same branch name; set upstream by default |
+| `git_fetch` | confirm | Fetch the Git-configured default or one optional remote |
+| `git_pull` | confirm | Pull the configured upstream or one optional remote; ff-only by default |
 
 ## Auth / safety
 
-- Mutating tools use confirm mode.
+- The four read tools execute bounded Git reads directly. The six confirm-mode
+  tools are semantic wrappers over the corresponding `GitRepository` record
+  actions.
+- Every action requires kernel confirmation. `branch`, `add`, and `commit` have
+  `write` effect; `push`, `fetch`, and `pull` have `external` effect.
+- A confirmed compatibility tool first calls `api.kernel.runAction(...)`. If the
+  kernel returns `KERNEL_CONFIRMATION_REQUIRED`, the wrapper retries once with
+  the returned confirmation grant because the host tool gate was already
+  approved.
+- Every `cwd` is contained by the active tenant coding root.
 - Force push and hard reset are **rejected** in this plugin.
+- Git is spawned directly without a Windows command shell.
 - Does not store credentials; uses the host git config / credential helper.
 
+## Verification
+
+`npm run validate` runs TypeScript checking, the Vitest contract/security/tenant
+suite, and the production bundle. The contract tests validate the ObjectType
+definition, action policy, API-version fail-fast behavior, semantic tool
+delegation, and confirmation-grant retry.
+
 ## Install
 
 Marketplace → Official → **Git**, or Unofficial with this repo URL. GodMode builds `dist/` on activate if needed.

data/ai/skills/git-workflow/SKILL.md

@@ -1,12 +1,28 @@
 ---
 name: git-workflow
-description: Local git workflow for Intelligence — status, diff, stage, commit, push via plugin tools
-tools: ["git_status", "git_diff", "git_log", "git_branches", "git_checkout", "git_add", "git_commit", "git_push", "git_fetch", "git_pull"]
+description: Local Git workflow for Intelligence using bounded read tools and confirmed GitRepository record actions
+tools: ["git_status", "git_diff", "git_log", "git_branches", "git_branch", "git_add", "git_commit", "git_push", "git_fetch", "git_pull"]
 ---
 
-1. `git_status` — note branch and dirty files.
-2. `git_diff` (and staged diff if needed) — summarize what will ship; exclude secret files.
-3. `git_checkout` with `create=true` when you need a feature branch (avoid committing straight to main unless asked).
-4. `git_add` with explicit pathspecs for the change set.
-5. `git_commit` with a concise message focused on why.
-6. `git_push` to origin (confirm). Then use **godmode-plugin-github** (`gh_pr_create`) when a pull request is needed.
+1. Start with the direct read tools: use `git_status`, then `git_diff`; use
+   `staged=true` to review the index or `base` (and optional `head`) for a
+   triple-dot range. Use `git_log` and `git_branches` when history or upstream
+   state matters.
+2. Use `git_branch` with `create=true` when a feature branch is needed. The same
+   tool checks out an existing branch with `create=false`; there is no
+   `git_checkout` tool.
+3. Use `git_add` with explicit pathspecs. Re-run `git_diff` with `staged=true`,
+   summarize exactly what will ship, and exclude secret files.
+4. Use `git_commit` with a concise message focused on why. Hooks run by default;
+   set `skipHooks=true` only when the user explicitly requests it.
+5. Use `git_fetch` or `git_pull` only when remote synchronization is needed.
+   `git_pull` is fast-forward-only by default.
+6. Use `git_push` to push `HEAD` to the same branch name on `origin` and set its
+   upstream by default. Then use **godmode-plugin-github** (`gh_pr_create`) when
+   a pull request is needed.
+
+`git_branch`, `git_add`, `git_commit`, `git_push`, `git_fetch`, and `git_pull`
+are confirm-mode compatibility tools over record actions on
+`GitRepository/coding-root`. They use the kernel client and its confirmation
+grant flow; do not call a legacy plugin route or construct an HTTP action
+request manually.

godmode.plugin.json

@@ -3,5 +3,6 @@
   "version": "0.1.0",
   "name": "Git",
   "engine": "^0.1.0",
+  "kernelApiVersion": 1,
   "bridge": { "entry": "dist/bridge.js" }
 }