[WebTigers]

Epic TIGER-334 — Phase 2 (TIGER-364), the ApiTransport commit spike

Leads Phase 2 with the module's biggest technical risk: creating a commit with no local git repo. Proves Tiger_Git_Transport_Api::commit() through the GitHub Git Data API:

1. read the branch head (ref) + its base tree
2. POST a blob per changed file (base64); a null-sha entry per deleted file
3. POST a new tree (on base_tree) then a new commit (parent = the old head)
4. fast-forward the branch ref (force:false) — a branch that moved under us is reported NON_FAST_FORWARD, never clobbered

With the API transport there's no local index, so commit() writes straight to the remote branch in one flow and push() is a verified no-op (committing is pushing). Also built: branches(), createBranch() (refuses the default branch). status/diff/switchBranch/pull/tag/listReleases/fetchArchive throw NOT_IMPLEMENTED — the rest of TIGER-364.

Safety / design

• HTTP is a seam (setHttp) → the whole flow is unit-tested against canned GitHub responses, no network.
• Token resolved per request via Tiger_Git_Credential (never held); every call pinned to api.github.com; redirects off.
• Errors map to stable, secret-free codes: 401→CREDENTIAL_INVALID, 403 rate→RATE_LIMITED, 404→INVALID_REF, 422 "fast forward"→NON_FAST_FORWARD.

Tests

10 unit (29 across the Git suite): the four-step sequence and payloads asserted (blob = base64 file content; tree builds on base_tree, deletion = null sha; commit parents the old head; ref update force:false), plus NON_FAST_FORWARD, missing-credential (no API call made), nothing-to-commit, empty-message, createBranch, branches, push no-op, NOT_IMPLEMENTED.

Stacking + next

• Stacked on PR Tiger_Git Phase 1 foundation — interfaces, env detection, credentials, data model (TIGER-334) #356 (Phase-1 substrate). Base will retarget to main once Tiger_Git Phase 1 foundation — interfaces, env detection, credentials, data model (TIGER-334) #356 merges.
• A live-GitHub integration test (throwaway repo + token) is the Testing-column gate — the mock proves the documented Git Data API contract shape.
• Next in TIGER-364: ShellTransport (git binary, host-agnostic), then the remaining ApiTransport verbs (status/diff/pull/tag/releases/archive).

🤖 Generated with Claude Code

https://claude.ai/code/session_01ASauLLscjqdsNqBNsx2Typ

[WebTigers]

Added ShellTransport (the git-binary path) on top of the ApiTransport commit spike. It implements far more of the interface (status/diff/commit/branches/createBranch/switchBranch/push/pull/tag), is host-agnostic, and is proven end-to-end against a real local repo + a bare file:// remote — including a genuine NON_FAST_FORWARD (forced via a second clone; push refused, never --forced) and verifying push/tag reach the remote. Token auth is injected via an inline credential.helper reading GIT_TOKEN from the env (never in argv or .git/config). listReleases/fetchArchive stay NOT_IMPLEMENTED (provider-API concern). 41 Git tests, 1172 unit — all green.

[WebTigers]

GitHubAdapter landed (8a172ba) — the provider layer that composes the two transports.

Tiger_Git_Provider_GitHub (implements the new Tiger_Git_Provider_Interface, the N-provider seam) picks the working transport per connection — the git binary where the host allows it, the API otherwise — for the git ops, and always routes the provider-API ops (listReleases/fetchArchive) to the API transport even on a shell connection, because a GitHub release is not a git concept (there's no git command for it). That routing is the adapter's whole reason to exist.

Implemented the two provider-API verbs on ApiTransport (their reason to exist):

• listReleases — newest first, drafts excluded.
• fetchArchive — GitHub answers the tarball endpoint with a 302 to codeload; the redirect is captured, its host re-checked against the allowlist, and the bytes streamed from the CDN without forwarding our token (the signed URL authenticates itself). send() now captures response headers for the capture.

Still NOT_IMPLEMENTED on the API: status/diff/switchBranch/pull/tag — the rest of TIGER-364 (a shell host reaches these via the working transport; an api-only shared host doesn't yet).

Tests: 10 new unit tests — routing proven with both seams (git-op→binary, api-op→API, release→API-even-on-shell), plus releases/archive incl. the 302 capture, the off-allowlist redirect refusal, and the bad-tag refusal. 68 Git, 1181 unit green; CAPABILITIES 244 classes.

[WebTigers]

Superseded by #358, which was squash-merged to main with the full stack (this PR's commits included). Closing — the changes are on main. (Kept open through review as the stacked chain #356←#357←#358.)