ZeqGit

ZeqGit is the framework's own git + PDF repository, live at zeq.dev/zeqgit. It is self-hosted (Gitea under the hood), branded as a standalone Zeq app, and wired into your Zeq identity so there is nothing extra to sign up for.

What you get

• One account. Sign in to the framework and your ZeqGit account is auto-provisioned — one ZID, one identity, single sign-on. No second login.
• Every project a repo. Opening a project creates a private repo; every file is versioned through it. Git over HTTPS, the full Gitea web UI underneath at /zeqgit/<you>/<repo>.
• PDFs you can actually read. PDFs and docs open inline in the ZeqReader (a Zeq-branded pdf.js viewer) instead of forcing a download. Large binaries use Git LFS.
• Every commit anchored. Each push is stamped with a ZeqProof — HMAC-SHA256(operator | result | zeqond) — on a hash-linked audit chain at 1.287 Hz. The chain is tamper-evident: each entry references the prior hash.

How it fits together

ZeqGit is a self-hosted git service fronted by a small bridge that ties it to the framework:

Concern	Mechanism
Identity / SSO	The bridge validates your framework v3 session token (POST /api/zeq-auth/verify-v3) — accepted from the zeq_auth_token cookie, an Authorization: Bearer header, or ?token= — provisions the matching Gitea account, and issues a signed cookie that Gitea's reverse-proxy auth turns into a transparent login. Guests hitting any Gitea route are redirected to the Zeq dashboard; Gitea's own login is never shown.
Repos & files	The bridge creates repos and commits files as you (admin API + Sudo), so authorship and permissions are yours.
PDF viewing	/zeqgit-bridge/view renders any repo file inline with pdf.js; /zeqgit-bridge/raw streams it with Gitea enforcing your permissions.
Audit chain	A push webhook writes a ZeqProof'd, hash-linked entry; /zeqgit-bridge/repo/activity exposes it.

Secrets (admin token, cookie/webhook/ledger secrets) live server-side and locked down — no .env, consistent with the ZSC policy. The service runs isolated in its own containers and cannot disturb the rest of the stack.

Endpoints (bridge)

POST /zeqgit-bridge/sso            # provision + sign-in (Bearer framework token)
POST /zeqgit-bridge/repo/ensure    # { project, files[] } → create + seed a repo
PUT  /zeqgit-bridge/repo/file      # { project, path, content } → commit a file
GET  /zeqgit-bridge/repo/list      # your repos
GET  /zeqgit-bridge/repo/tree      # ?repo=<name> → file list
GET  /zeqgit-bridge/repo/activity  # the ZeqProof audit chain
GET  /zeqgit-bridge/view           # ?repo=&path= → ZeqReader (inline PDF/doc)
GET  /zeqgit-bridge/raw            # ?repo=&path= → raw bytes (permission-checked)

The full Gitea web UI (issues, PRs, branches, releases, packages, CI) is available underneath at /zeqgit/<owner>/<repo> once you're signed in.

What lands in ZeqGit automatically

Your work flows into ZeqGit without leaving the tools you build in:

• Workbench projects. Every project you build in the Workbench becomes a private repo; its spec.md, plan.md, and generated page/app files are committed for you.
• State contracts. Contracts you generate/deploy in the Contract IDE are mirrored into a per-user state-contracts repo; contracts built through Workbench land in that project's repo. Every push is ZeqProof-anchored.
• One identity, themed everywhere. ZeqGit, its API/Swagger reference, the dashboard, Workbench and the Store all carry the same Zeq navigation bar and mint-on-near-black DNA, signed in on your single ZID.

In your editor and your browser

ZeqGit isn't only a website — the same per-project repo system ships in both first-party extensions, driven by one shared module so the web, the editor, and the browser can never drift. Every project gets a unique repo (name-<hash>); the hash is derived from stable content so reopening re-binds to the same repo, and a rename keeps it — renaming never forks a new repo.

• VS Code — your workspace folder is a repo. The open folder binds to its own private repo (named from the folder, confirm/rename prompt). Zeq: Sync workspace to ZeqGit mirrors the workspace as ZeqProof-anchored commits; Zeq: Open this workspace's ZeqGit repo and the success notification link to the repo and the Observer. Optional zeq.zeqgit.autoSave mirrors each file on save, and a status-bar item shows the bound repo.
• Chrome — Workbench + ZeqGit in-panel. The side panel hosts the live Workbench, the ZeqGit dashboard, and the Observer (signed in via the auth bridge), so the name-your-app prompt, per-chat repos, automatic file / page / contract save, and the file-aware dashboard are all present right in the browser.
• Workbench and the CLI mirror the same way on the web — every Pulse chat is its own repo, and each CLI bind lands in the contract's repo.

The dashboard is file-aware

The ZeqGit dashboard (zeq.dev/zeqgit) is a developer's view of your project, not just a list of files. Select a repo and you get:

• File tree grouped by folder (pages/, contracts/, scripts, notes, …) with type-aware icons.
• Live apps. A deployed page (pages/<name>.html) is flagged ● LIVE with a launch link straight to /s/<slug>/p/<name>/, alongside a link to its source file.
• Executing state contracts. Each contract shows its executions per zeqond (the contract's zeqond_tick_rate), fires total, next fire, current state and target. A fire ▶ button executes the next transition (/api/chain/<slug>/contracts/<id>/fire-now); each fire returns a ZeqProof and the fire count ticks up. Guarded transitions (a condition on the next step) report their reason instead of firing blindly.
• Connected APIs, each on its own card. The kernel SDK (/s/<slug>/sdk/zeq/compute), the entangled-state chain, any contract webhooks, and the endpoints each deployed page calls (detected by scanning the page source) — so a developer sees the whole application: its files, what executes, and what it's wired to.