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

@@ -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