alkdev/alkforge
6
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: deployment walk enumerates the live gitea surface (OQ-FG-01)

Browse Source 
- behavior-only walk of git.alk.dev (gitea 28.3.0): findings in
  docs/research/deployment-walk.md
- headline: forge is a git host + public landing page only (issues/
  PRs/wiki/releases/LFS/CI all zero-usage inertia); whole-org
  anonymous read is the operative grant; single-branch direct-push
  model by per-agent accounts; tags are the release surface
- phase-0.md: sect 3 filled with summary + link, OQ-FG-01 resolved
  with residues, asks list gains the verified web-browse-queries
  item, POC item 1 marked done, checklist item checked
This commit is contained in:
glm-5.3-flash committed 2026-11-07 13:30:59 +00:00
1 parent e6867eaaed
commit 620a41c6a2
2 files changed
+418 -22
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

docs/research/deployment-walk.md
+346
View File
@@ -0,0 +1,346 @@
---
status: draft
last_updated: 2026-11-07
---
# The gitea deployment walk (OQ-FG-01)
Behavior-only enumeration of the live gitea deployment at `git.alk.dev`,
per the phase 0 walk rules (`phase-0.md` sect 3; AGENTS.md convention
13: behaviors from the outside, never gitea's source). This document
fills the sect 3 template with real findings and states what remains
unverifiable from outside.
## 1. Method and provenance
What was inspected, and how it was kept behavior-only:
- **Anonymous web/API surface**: the deployment was fetched without
credentials the way any visitor would (explore pages, gitea's public
API endpoints, wiki URLs). This both enumerates the anonymous
surface and directly observes what an anonymous peer can see.
- **SSH git door**: the `git@git.alk.dev` SSH endpoint was probed the
way git clients use it (`git ls-remote`, mirror clones). The session
key (`glm-5.3-flash`) is registered on the forge as a personal key,
so the probes are authenticated-user behavior, not admin behavior.
- **Repo contents**: all 35 `alkdev` repos were mirror-cloned
(`~60 MB total`) and analyzed offline: refs, tags, commit
authorship/dates, file trees, `.gitattributes`/submodule/CI-config
presence, largest blobs. Commit history metadata is behavior
evidence of the deployment's usage, not source reading.
- **Deployment shape**: `reverse-proxy`'s `deploy/` artifacts
(`docker-compose.yml`, README) describe the standing front-door
topology including the gitea container next to it. These are the
repo's deploy examples rather than the live host's files, so they
are treated as indicative topology, not ground truth (see sect 8).
- **Not inspected**: gitea source, the host's `app.ini` or its access
logs: this environment has no host shell, and the behavior-only rule
excludes the source in any case. Gitea's version (28.3.0) came from
the deployment's own public API endpoint, which is itself a walk
finding.
Pacing note (rate-limit safety): every live request ran sequentially
with small sleeps; total live traffic for the walk was under 100
requests and one 60 MB of mirror fetches. Nothing bursted.
## 2. Deployment census
| Fact | Finding | How observed |
|---|---|---|
| Software | gitea 28.3.0 | anonymous `GET /api/v1/version` |
| Orgs | one: `alkdev` (public visibility) | anonymous API |
| Repos | 35, all `private: false`; 34 non-empty (`alkdev/ade` is empty) | anonymous API |
| Users | 7: `alkimiadev`, `bot`, `deepseek-v4-flash`, `deepseek-v4-pro`, `glm-5.1`, `glm-5.2`, `glm-5.3-flash` | anonymous `/api/v1/users/search` |
| Stars/forks/watchers | 0 across the org | anonymous API |
| Front door | reverse-proxy (TLS, fail2ban, rate limits) in front; gitea container + postgres 16 behind compose | reverse-proxy `deploy/` artifacts |
| SSH door | `git@git.alk.dev:22`; gitea-managed keys; "Gitea does not provide shell access" | live SSH probes |
Two structural observations the census already supports:
1. **The "web view for the OSS projects, public clones for them" ADR
scope sentence undershoots present reality.** The deployment is not
"some OSS projects public": the entire org, all 35 repos, is
anonymously readable, through the web UI, the JSON API, and both
git transports (verified anonymous smart-protocol HTTP clone). The
existing public surface is *everything the forge serves*, web and
git alike. A per-repo public flag (phase-0 sect 5 draft posture) is
a strict refinement of a currently coarser de-facto org-wide
anonymous-read grant, not a departure.
2. **The anonymity is unauthenticated by construction.** An anonymous
visitor gets repo listings, file trees, server version, user
roster, and full clones. This is the operative peer model today,
and it is exactly the OQ-FG-03 anonymous identity class, already
used by real consumers. The roster exposure is worth noting: gitea
publishes the account list (agent identity names included) to
anonymous visitors.
## 3. Door-by-door behavior
### Web (browser, anonymous)
Anonymous `HTTP 200` on: home, `/explore/repos`, repo pages (e.g.
`/alkdev/alkforge`), wiki pages, and the JSON API at
`/api/v1/...` (`/version`, `/repos/search`, `/users/search`,
per-repo `/issues`, `/pulls`, `/releases` listing endpoints). The
API's swagger root also responds anonymous. Gitea thus exposes its
full web application as the anonymous-authorized surface, version
number included (CVE-planning-free visibility into the exact code
version: one of the standing exposure classes alkforge removes by
being a smaller, named surface).
### HTTP git transport
Anonymous `git clone https://git.alk.dev/alkdev/alkfs.git` succeeds
(smart v1/v2 negotiation, real clones fetched). Public clone over
HTTP is live, anonymous, and evidently the intended model.
### SSH git transport
- `ssh git@git.alk.dev` (no command): authenticates the per-agent
key ("Hi there, glm-5.3-flash! You've successfully authenticated
with the SSH key named glm-5.3-flash"), then states that gitea
provides no shell access. So the SSH door *is* the git door; shell
is a declined path, by design.
- Path grammar: `ssh://git@git.alk.dev/alkdev/<repo>.git` works.
Bare `<repo>.git` (no owner) answers `error: Invalid repository
path`; a nonexistent owner/repo answers `error: Cannot find
repository <owner>/<repo>`. The two error classes are
distinguishable from outside (a mild repository-existence oracle,
only useful pre-auth, which the family's doors would not preserve
anyway).
- Write behavior was not probed live (the walk avoids mutating the
forge), but the commit history settles the write pattern: direct
pushes to `main` by the per-agent accounts, no PR flow, no
protected-branch bypass drama (see sect 4). Every agent identity's
SSH key maps to a gitea account that commits straight to `main`.
### LFS / large media
Zero `.gitattributes` in any of the 35 repos at any inspected
branch/HEAD; zero LFS pointer files; largest blobs in the whole org
are `typemap`'s Blender design files (`design/typemap.blend*`, max
~3.2 MB). The repo totals are tiny: biggest is `typemap` (~10 MB),
the whole org sums to ~60 MB. **LFS is unused.** The largest media
the family forge has ever carried rides ordinary git objects
comfortably.
### Issues, PRs, wiki, releases, projects
Zero of everything, org-wide, across all history: 0 issues, 0 pull
requests, 0 gitea releases, 0 wiki pages (every `/wiki/raw/Home`
returns 404; the `has_wiki`/`has_issues` flags are on but empty:
default-flag inertia), 0 stars/forks/watchers. The forge is used as
a git host and a landing page. Nothing else.
## 4. Repo-content census (the usage evidence)
Full data in the walk notes; summarized per repo (branch count
excludes `main`; commits counted across all refs):
| Repo | Br | Tags | Commits | Activity window | Notes |
|---|---|---|---|---|---|
| alknet | 1 (develop) | 0 | 636 | 2026-06 only | largest by commits; dormant since June |
| alkhttp | 0 | 10 | 212 | 2026-08 to 2026-10 | earliest branch work by `deepseek-v4-flash` |
| alkgit | 0 | 2 | 171 | 2026-09 to 2026-10 | per-crate tags (`alkgit-v0.1.0`, `alkgit-substrate-v0.1.0`) |
| alkblobs | 0 | 4 | 155 | 2026-09 to 2026-10 | |
| alkstore | 0 | 1 | 153 | 2026-10 | |
| reverse-proxy | 1 (stale) | 0 | 184 | 2026-06 to 2026-10 | |
| alkcall | 0 | 15 | 109 | 2026-08 to 2026-11 | most release tags in the org |
| alktype | 2 (POC) | 4 | 90 | 2026-07 to 2026-09 | |
| alktunnels | 0 | 7 | 81 | 2026-09 to 2026-11 | |
| alkssh | 0 | 2 | 81 | 2026-10 to 2026-11 | per-crate tags (`alkssh-v0.2.0`) |
| alktty | 0 | 11 | 57 | 2026-08 to 2026-11 | |
| typemap | 0 | 0 | 56 | 2024-12 to 2026-04 | **imported with upstream history** (`sinclair`) |
| taskgraph_ts | 0 | 0 | 66 | 2026-04 only | |
| flowgraph | 6 (stale) | 0 | 96 | 2026-05 only | single-month experiment cluster |
| pubsub | 3 (stale) | 0 | 37 | 2026-04 to 2026-05 | |
| wraith | 12 (stale) | 0 | 59 | 2026-06 only | |
| typebox | 0 | 0 | 15 | 2025-12 to 2026-04 | **imported with upstream history** (`sinclair`) |
| alkforge (this repo) | 0 | 0 | 3 | 2026-10 to 2026-11 | |
| open-memory, open-tasks, operations, hub, dbtype, drizzlebox, cograph, storage, alkfs, alkjs, alknet-firewall, alkgit-adjacent small repos | 0 | 0 | 2-12 each | short initial windows | |
| ade | 0 | 0 | 0 | (empty) | never committed |
Whole-org totals: 2607 commits; ~2600 of them in 2026-04 through
2026-11 (peak month 599, 2026-06). Authorship: `glm-5.1`, `glm-5.2`,
`glm-5.3-flash`, `deepseek-v4-flash`, `deepseek-v4-pro`, plus the
upstream `sinclair` history inside the two imports.
Usage patterns this census establishes:
- **Single-branch development.** Almost every active repo develops
exclusively on `main`. The non-`main` branches are leftovers: one
stale feature branch (`reverse-proxy`), `alknet`'s `develop`
(dormant since June), and single-window experiment clusters
(`flowgraph`, `wraith`, `pubsub`, `alktype`'s two POC branches).
Branches are not a load-bearing workflow; `main` + push is.
- **Direct push to main, no PR flow.** Confirmed by 0 PRs org-wide
plus per-agent commit authorship on `main`. Review happens outside
forge-side workflow (in opencode sessions); the forge is the
landing zone, not the review surface.
- **Tags are the release surface.** 87 semver tags across 15 repos,
matching published crate versions; multi-crate repos prefix tags
per crate (`alkgit-v0.1.0`). No gitea release objects, no release
notes, no attachments: tags and the web browse of them are all
downstream consumers (and crates.io, via CI elsewhere) see.
- **Full-history imports exist.** `typebox` and `typemap` carry
upstream (`sinclair`) history from 2024/2025, i.e. external repos
were imported with their full history at least once. Migration
must preserve import histories or these two repos break their
upstream-diff ability.
- **7 of 35 repos have no README at HEAD** (`alkfs`, `alkjs`,
`alknet-firewall`, `cograph`, `hub`, `open-tasks`, `storage`): the
web view must render repo landings without a README gracefully,
and "readmes are optional" is the actual family expectation.
- **No submodules in any repo, ever.** No CI workflow files anywhere
(`.gitea/workflows/`, `.github/workflows/`, `.woodpecker/`,
`.drone*`, `.gitlab-ci*`: zero hits): forge-side CI never operated.
Verification happens in the development sessions; crates.io
publishing is driven from those sessions too.
## 5. The three-bucket classification
Walk rule 2 (sect 3 of phase-0): every finding lands in load-bearing,
inertia, or deferred.
**Load-bearing (must appear in the 0.1 spec):**
1. Anonymous HTTP smart-clone of all org repos (whole-org public
read; the de-facto grant is org-level, not per-repo).
2. Authenticated SSH git, read and write, with direct push to `main`
by per-agent identities (no PR flow, no branch hygiene to enforce).
3. Single-branch (`main`) model with an `alknet/develop` branch to
preserve through migration.
4. Tags as the release surface (87 tags; per-crate prefixing;
migration must carry them; version-tag browsing is the natural
minimal web surface).
5. Minimal web view: org/repo listing and repo landing with file
browse (gitea's anonymous UI is the only current web surface, so
the pages are actually the org's public frontend; sect 8 records
what is still unknown about which pages are *visited*).
6. Full-history git imports of external projects (`typebox`,
`typemap`): the 0.1 migration path must handle import-style
histories; `clone-push` covers it, but it must be on the checklist.
7. Account model as it actually exists: one human admin, one `bot`,
five agent identities, one key each: admin-provisioned, invite-to
-work territory, exactly OQ-FG-04's expected small set.
8. No README is normal: the web view cannot assume one.
**Inertia (dropped in 0.1, with a migration note):**
- Issues, pull requests, wiki, gitea projects, gitea releases UI,
stars/forks/watchers: flags may be on, usage is zero and always
was. Migration note: document that these features were unused, so
the cutover does not silently strand workflows.
- Empty repo (`alkdev/ade`): create or drop as the owner chooses.
- Experiment/stale branches outside `main` (except `alknet`'s
`develop`): branch-delete on cutover or preserve for archaeology,
but spec-irrelevant either way.
- The JSON API as a user-facing surface (no known API consumers;
the family's tooling operates over git + local session state, not
the forge API). Confirmed-unknown: any external anonymous API
consumer would be indistinguishable from web browsing here.
**Deferred (real-but-not-yet or later-version):**
- LFS: unused today (heaviest blob 3.2 MB). The alkblobs/alkgit
ADR-022 LFS door can be deferred with confidence; keep a watch for
future large design media, which would be the trigger to turn it
back on.
- Forge-side CI: never operated; not a 0.1 concern.
- Everything else in gitea's broad feature set (packages, actions,
mirror sync webhooks, ...): zero evidence of use.
## 6. Sizing implications (what the walk changes)
- **The web view is truly minimal.** With issues/PRs/wiki/releases
all empty, the pages that matter are: the org/repo list ("what
repos exist"), repo landing (README when present + clone lines +
latest tag), file/directory browse at a ref, and tag browsing.
OQ-FG-05's draft hunch is confirmed and slightly extended: **tag
list and commit log are the only history-shaped pages with a
real basis**, and both need cheap ref/object queries (the
phase-0 asks list item 4 to alkgit: producer-half queries for UI
purposes gains a concrete, verified use).
- **Public read is the org default today.** OQ-FG-03's anonymous
identity class is not hypothetical; it is the dominant peer class
of the current deployment. Rate-limit/abuse posture for that class
(fail2ban + rate limits at reverse-proxy, per sect 2) moves to
alkforge's door assembly when gitea exits.
- **Write/permission model is simpler than the draft table
anticipated.** Trusted per-agent accounts push straight to `main`
on all repos (org-level collaboration). The per-repo grant list in
phase-0 sect 5 remains right for the model; present reality is
"one org, everyone in it writes `main` everywhere". Migration: six
writable identities plus the human admin.
- **Migration shape (OQ-FG-07).** ~60 MB, 35 repos, 2607 commits,
87 tags, two import histories: `mirror fetch + push` through the
protocol halves is plainly sufficient for all of it. Nothing needs
gitea-side export formats; account/key data regeneration is the
only non-git work (seven accounts, seven-plus keys, alkvault
references).
- **Anonymous exposure shrinks massively.** Today an anonymous peer
sees the gitea web app, the JSON API, the user roster, and the
exact server version. The 0.1 web view plus nameless git serving
(no roster page, no version endpoint) is a large standing-exposure
cut, consistent with ADR-002's motivation.
## 7. What the walk confirms about the upstream asks (sect 6 of phase-0)
- **ask 1 (alkgit auth/identity surface for consumers)**: confirmed
real: write happens with per-identity ACL decisions before
receive-pack (and today's deployment does the same via gitea's
auth hook).
- **ask 2 (anonymous public-read serving posture)**: confirmed
load-bearing: the anonymous read path is the most-used door in the
current deployment by consumer count (every clone of every repo).
- **ask 5 (alkhttp anonymous git door)**: confirmed as the actual
public-clone mechanism in use today (anonymous HTTP clone verified
live).
- **new ask item (now phase-0 asks list item 4 to alkgit)**: the
minimal web view has a verified need for cheap ref/object listing
queries (tree at ref, recent commit log, tag listing) beyond
protocol halves, whether served from alkgit or alkstore metadata;
OQ-FG-05 carries the disposition.
## 8. Not verifiable from outside (open verification items)
These need host access or user knowledge; they do not block the 0.1
spec as walked, but each is a residual risk on its assumption:
1. **Visit/traffic patterns**: no logs available in this
environment. Which web pages are actually visited (repo pages vs
API vs explore), and how much web traffic the clone doors get, is
unmeasured. The web view sizing in sect 6 rests on the surface
being *exposed*, not on visit data. Measure at reverse-proxy
(`/var/log/reverse-proxy/access.log`) before freezing the 0.1 web
spec if there is any doubt.
2. **How the outside links in** (what URLs get pasted/linked
externally: file permalinks? repo pages?): no observation path
from outside. If external links to blob lines exist, the web view
needs line-permalink stability sooner than 0.1 assumptions allow.
3. **Host-side configuration** (`app.ini` customizations beyond
defaults, whether issues/wiki were ever configured and abandoned
vs never configured): the flags-on-but-empty pattern suggests
never-set-up-then-inertia, unconfirmed.
4. **SSH key inventory** (how many keys per account, key material
age/algorithm) and **who else holds keys**: observable only at
the host; the account roster (7 accounts) came from the public
API instead.
5. **Non-git SSH usage** (tunnels/port-forwards via the SSH door):
the door's structure (gitea, forced git command, no shell)
strongly suggests none; nothing in the family repos or deploy
artifacts indicates a shell-capable channel. Confirm at cutover
so no silent dependency breaks.
6. **Backup layout** (the "three locations" from ADR-002's context),
so migration can verify data-integrity posture before cutover.
## 9. Provenance of numbers
- Gitea version, org/repo/user rosters, per-repo flags: anonymous
`https://git.alk.dev/api/v1/...` (2026-11-07).
- Repo content stats (commits, tags, branches, blobs, README/CI/
.gitattributes/submodule checks): offline analysis of 35 mirror
clones fetched over the SSH door (2026-11-07).
- Error-mode and no-shell behaviors: live SSH probes, same day.
- Deployment topology: `reverse-proxy/deploy/docker-compose.yml` +
`deploy/README.md` (repo examples, confirm at host).
docs/research/phase-0.md
+72 -22
View File
@@ -16,9 +16,10 @@ exact feature set and Phase 0 shape) and OQ-07 (the alkgit asks list).
This is a **draft**: the sections below record what is already settled
by family decisions and published crates, then set up the work items
that still need real research. The load-bearing-surface enumeration
(§3) is explicitly incomplete and must be driven by a walk of the live
gitea deployment (behaviors only, never its source, see AGENTS.md
convention 13).
(§3) has been walked against the live deployment
([`deployment-walk.md`](deployment-walk.md)); the remaining work items
are the web-view disposition (OQ-FG-05), the git round trip (§8.2),
and the SSR spike (§8.3).
## 1. What alkforge is
@@ -104,11 +105,33 @@ wiring, configuration, and the web surface.
## 3. The load-bearing gitea surface (work item #1)
OQ-06 requires enumerating what the gitea deployment is *actually*
used for, separating load-bearing surface from inertia. This repo was
initialized before that walk happened, so what follows is the
provisional list implied by family ADR-002's own scope sentence, each
item marked with what must be confirmed against the live deployment:
**Status: walked.** The live deployment (`git.alk.dev`, gitea 28.3.0)
was enumerated behavior-only on 2026-11-07; the full findings,
method, per-repo census, and three-bucket classification are in
[`deployment-walk.md`](deployment-walk.md). The headline results:
- The forge is used as a git host and a landing page, nothing else:
0 issues, 0 PRs, 0 wiki pages, 0 gitea releases, 0 stars/forks
org-wide across all history; no LFS (heaviest blob ~3.2 MB); no
submodules; no forge-side CI. Issues/PRs/wiki/releases are inertia.
- All 35 `alkdev` repos are anonymously readable today (web, JSON
API, HTTP clone, SSH read); the de-facto public-read grant is
org-wide, and the anonymous peer class is the deployment's
dominant consumer class (OQ-FG-03 confirmed operative).
- Development is single-branch (`main`) with direct pushes by five
per-agent accounts plus a human admin and a `bot`; no PR flow.
Tags are the release surface (87 semver tags, per-crate prefixed).
`typebox`/`typemap` carry full-history upstream imports.
- Migration (OQ-FG-07) is easy: ~60 MB total, 2607 commits,
mirror-fetch + push suffices; account/key regeneration is the only
non-git work (7 accounts).
- Residue that cannot be observed from outside (visit patterns,
external inbound links, host config, key inventory): recorded in
the walk doc's sect 8 with the measurement point for each.
The original provisional table and rules below are preserved for
traceability; the filled-in version superseding them is in the walk
doc:
| Need | Implied serving shape | To verify on the deployment |
|---|---|---|
@@ -217,21 +240,27 @@ the owning repo; nothing here is implemented in alkforge instead):
3. SSH wiring: confirm the alkssh `git` feature's channel mapping
matches alkforge's needs end to end (it shipped with alkforge as
the named first consumer; gaps found become asks, not workarounds).
4. Web-browse queries for the minimal UI (commit log, tree at ref,
tag listing): the deployment walk
([`deployment-walk.md`](deployment-walk.md) sect 7) verified the
need from real usage (tags are the family's only release surface;
the web view is the org's public frontend), and OQ-FG-05 carries
the disposition (alkgit vs alkstore metadata).
**To alkhttp:**
4. The git door's anonymous-request shape (public clone without an
5. The git door's anonymous-request shape (public clone without an
identity), including how it composes with reverse-proxy in front.
**To alkgen:**
5. OQ-GN-09 residue: alkforge's SSR library posture (in-process
6. OQ-GN-09 residue: alkforge's SSR library posture (in-process
render-per-request vs pre-rendered) and whatever the first real
render turns up (0.1.0 exists precisely to be shaken by this).
**To alkcall:**
6. Only if the ACL wiring hits substrate gaps; the visible-surface =
7. Only if the ACL wiring hits substrate gaps; the visible-surface =
authorized-surface model looks sufficient for the draft posture.
The asks-list discipline from the family ledger: early consumers file
@@ -246,7 +275,12 @@ open-questions.md` in Phase 1. Order below is rough priority.
Section 3's walk. Blocks the 0.1 feature freeze, the migration plan,
and the web-view spec. Highest priority; everything downstream sizes
from it.
from it. **Resolution (2026-11-07): walked and answered modulo the
outside-observable residues in the walk doc's sect 8** (visit
patterns, external inbound links, host-side config, SSH key
inventory, non-git SSH confirmation, backup layout: none of which
blocks the 0.1 spec as walked). See
[`deployment-walk.md`](deployment-walk.md).
### OQ-FG-02: What is alkforge 0.1's binary/service shape?
@@ -278,13 +312,17 @@ distributed-platform goal lives in alkgit, not here.
### OQ-FG-05: What does the web view render in 0.1?
The page list sizes from OQ-FG-01. Draft hunch: project listing, repo
landing (README + clone lines), file browse/download. Commit browsing
scope (log, tree, diff) is a real 0.1 question: alkgit serves protocol
operations, not web-browse queries; the ask list (§6.2/6.3 territory)
may need an item for cheap ref/object queries for UI purposes, vs
serving them from alkstore metadata. HTML sanitization policy for
README rendering is part of this question.
The page list sizes from OQ-FG-01 (now walked: see sect 3;
[`deployment-walk.md`](deployment-walk.md) sect 6). Confirmed page
basis: org/repo listing, repo landing (README optional: 7 of 35
repos have none; clone lines, latest tag), file browse/download,
tag list, and commit log: the only history-shaped pages with a real
basis. alkgit serves protocol operations, not web-browse queries;
the asks list now carries the explicit item (§6.4) for cheap
ref/object queries for UI purposes, vs serving them from alkstore
metadata: OQ-FG-05 still owns the disposition (which of the two
serves what). HTML sanitization policy for README rendering is part
of this question.
### OQ-FG-06: Config file and storage layout?
@@ -333,12 +371,19 @@ priority (each run per the POC-placement rules in
1. **Deployment walk** (not a POC; pure research): the §3 gitea
surface enumeration. Blocks OQ-FG-01 and most sizing decisions.
**Done (2026-11-07):**
[`deployment-walk.md`](deployment-walk.md). The walk also moved
OQ-FG-01 to resolved-with-residue, confirmed upstream asks 1/2/4
as load-bearing, and sharpened OQ-FG-05 (tag list + commit log
are the only history-shaped pages with a real basis).
2. **End-to-end git round trip through the assembled doors** (likely
thin over alkssh's and alkgit's existing test coverage; only run
what the crates do not already prove): clone + push over alkssh git
mapping and over alkhttp's git feature against an
alkgit-substrate backend, with an ACL grant/decline matrix. Validates
§4's composition and the asks list items 1/2/4.
§4's composition and the asks list items 1/2/5; the deployment
walk confirmed all three are load-bearing (anonymous clone is the
current deployment's dominant door).
3. **SSR first-consumer spike**: one repo-landing page through alkgen
0.1.0 behind an alkhttp op, with strict-mode failure and
determinism tests. Validates item 5 (OQ-GN-09 residue) from
@@ -346,8 +391,10 @@ priority (each run per the POC-placement rules in
## 9. Convergence checklist (what Phase 0 must produce)
- [ ] Load-bearing gitea surface enumerated (OQ-FG-01; §3 template
filled with real findings)
- [x] Load-bearing gitea surface enumerated (OQ-FG-01; §3 template
filled with real findings: see
[`deployment-walk.md`](deployment-walk.md); residues that need
host access are listed there in sect 8)
- [ ] 0.1 feature freeze list agreed from those findings
- [ ] Stack mapping validated (§4) against the real surface; updated
with door gaps
@@ -389,3 +436,6 @@ priority (each run per the POC-placement rules in
precedent)
- The gitea deployment itself: live inspection target for §3
(behavior only)
- Deployment walk findings:
[`deployment-walk.md`](deployment-walk.md) (the §3 work item's
output; live deployment enumerated 2026-11-07)