From 9888922ff625e94e54a8767437918a8ee83464d7 Mon Sep 17 00:00:00 2001 From: "glm-5.3-flash" Date: Sun, 8 Nov 2026 13:00:44 +0000 Subject: [PATCH] docs(phase0): record owner answers to the survey's flagged questions Answers for the four sect 5 questions: minimal human-only authenticated surface (console-vs-server-side stays open for requirements.md), archive downloads with a named trigger, per-identity email over the alk.dev catch-all as a stated transparency requirement, and an admin-action audit trail accepted as family-posture material --- docs/research/gitea-feature-survey.md | 49 +++++++++++++++------------ 1 file changed, 27 insertions(+), 22 deletions(-) diff --git a/docs/research/gitea-feature-survey.md b/docs/research/gitea-feature-survey.md index 0997bc6..52a82a7 100644 --- a/docs/research/gitea-feature-survey.md +++ b/docs/research/gitea-feature-survey.md @@ -134,29 +134,34 @@ posture, **V** = verified usage (walk or sect 2). downloads (#23), plus the cross-cutting inbound-link (#2) and audit-trail (#24) capability questions. -## 5. Flagged questions for owner input +## 5. Flagged questions: owner answers (2026-11-08) -1. **Authenticated web surface and second factor.** gitea today has - no 2FA and no live sessions, and admin work happens server-side. - If alkforge 0.1 renders a read-only public web view only, the - second-factor question is moot at that milestone. Does the owner - want any authenticated web surface (an admin console, account - self-service) in the visible roadmap at all, and if so with what - security class? Alternatively the whole admin surface could stay - server-side (config + alkstore + alkvault), leaving the web view - permanently unauthenticated. -2. **Archive downloads on the public web view.** Cheap capability, - but it is one more public serving path with the crawl-abuse - precedent attached. In scope for 0.1, later, or not at all? -3. **Email in the account model.** gitea requires email addresses; - the family accounts are agent identities that have none. Does the - human account need one (for what?), or is the account model - email-free? -4. **Admin-action audit trail.** gitea's `audit_event` arrived - recently and is unused here. Separately from gitea entirely: - should identity/grant/config changes in alkforge produce an audit - record (alkstore rows, tracing with bounded retention), or is - standing system-level logging sufficient? +1. **Authenticated web surface and second factor.** Owner: only the + human uses authenticated web endpoints today (repo creation + mostly), and the family's distrust of forge-side features is the + standing reason usage stayed minimal (the replacement plan always + aimed closer to actual need). Disposition for requirements.md: the + authenticated surface stays minimal and human-only; whether 0.1 + has a web console or does administration server-side (config + + alkstore + alkvault) is decided there; second-factor security is + moot until an authenticated web surface exists at all. +2. **Archive downloads on the public web view.** Owner: useful later, + low priority. Named trigger (requirements.md/roadmap territory): + archiving earlier-stage js projects as they get replaced by newer + work. Not a milestone-1 item. +3. **Email in the account model.** Owner: required. Each LLM gets its + own account for transparency, future training data, and git + interoperability, with addresses under the alk.dev catch-all. + Authorship rides per-identity emails end to end today (gitea's + push-mirroring preserved agent authorship to GitHub, e.g. the + glm-5.1 taskgraph_ts commit). Requirements anchor: identity + transparency is a stated family value, not a git-protocol + accident; the account model carries a per-identity email as part + of the identity row. +4. **Admin-action audit trail.** Owner: yes, it makes sense. Lands in + requirements.md as a family-posture requirement covering identity + lifecycle, grants, and config changes; shape (alkstore rows, + tracing with bounded retention, or both) decided there. ## 6. What this document is not