diff --git a/docs/research/deployment-walk.md b/docs/research/deployment-walk.md new file mode 100644 index 0000000..097b3f7 --- /dev/null +++ b/docs/research/deployment-walk.md @@ -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/.git` works. + Bare `.git` (no owner) answers `error: Invalid repository + path`; a nonexistent owner/repo answers `error: Cannot find + repository /`. 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). diff --git a/docs/research/phase-0.md b/docs/research/phase-0.md index 119c1e8..6604766 100644 --- a/docs/research/phase-0.md +++ b/docs/research/phase-0.md @@ -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)