Elnor Repo Reader

ELNOR REPO READER TEXT MIRROR
Original path: Current Specs/DOC73/DOC73_V1_6_ADJUDICATION_CARD_ARCHITECT_NOTES_V1 (1).md
Source repo: /Users/OpenClaw1/Elnor/Elnor Specs
Git branch: main
Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331
Generated: 2026-06-09T01:23:58.539Z

---

# DOC73 V1.6 Adjudication Card — Architect Supplemental Notes

**Document ID:** `DOC73_V1_6_ADJUDICATION_CARD_ARCHITECT_NOTES_V1`
**Status:** Working notes captured during the red-team round period (between sending the inventory red-team prompt and aggregating reviewer responses).
**Purpose:** Capture architect thinking that arrives outside the formal review channel so it's not lost. These get folded into the V1.6 adjudication card alongside reviewer responses.
**Date opened:** 2026-04-29

---

## Note 1 — Share-link UI shape (architect-supplied 2026-04-29)

**Source:** Architect direct guidance during inventory red-team waiting period.
**Affects:** Group I (share-link sessions + session profile primitive); cross-references to Group L (UI complexity tier = `minimal` defaults).
**Disposition target:** V1.6 spec drafting, Group I + DOC20 R-next webpage UI section.

### What the architect specified

When a remote user opens a share-link, the page should show:

- **Primary:** A chat window (the main interaction surface). The user types queries, gets responses.
- **Settings drawer / dropdown** on the side that opens to expose:
  - **Corpus selection:** A list of all corpora and other ELNOR aspects the user has been invited to join, per their session profile's permissions. Multi-select supported.
  - **Multi-corpus search toggle:** When multiple corpora are selected, the user can choose to search across all selected corpora or restrict to one at a time.
  - **Capability indicators:** Other Elnor aspects the user has access to via their profile (e.g., specific DOC23 tasks if Group I extensibility is exercised).
- **Upload documents button:** Visible action to contribute documents to whatever corpus is currently active (subject to per-share-token `document_ingestion_permission` flag from the session profile schema).
- **Download affordance for documents:** Any document Elnor delivers in response to queries should be readily downloadable.
- **Artifacts panel** (a la Claude.ai's artifacts surface): A persistent panel storing references to anything the agent has produced or surfaced during the session (documents delivered, generated content, links). Click to open or download. Persists for the session lifetime.
- **Authentication required:** Architect agreed the link cannot be unauthenticated. A passcode (or other authorization mechanism per Group H eventual networking spec) must gate access. Inventory framing was already heading this way — this confirmation locks it in for V1.6 even before networking spec lands.

### Why this matters for the spec

The architect's specification clarifies the **default share-link UI shape** that Group I needs to deliver. Without this, the inventory's framing of "Mode 1 = read-only chat with constrained capabilities" was structurally correct but visually underspecified — leaving "what does the user actually see" as a drafting-time decision.

This note moves that decision out of drafting-time and into inventory-time. V1.6 spec drafting for Group I now has a concrete UI starting point.

### Forward-looking notes

The architect said: "Eventually we could add the filtering browser type stuff there but that's what I want the initial page to look like." This locates **filter UI (J.5) within the share-link surface** as future work, not initial scope. V1.6 ships the basic chat + settings drawer + corpus selector + upload + downloads + artifacts panel + auth. Filter pane within share-link UI is V1.7+ refinement.

### Specific spec impacts

When V1.6 drafting begins, this note should drive:

1. **DOC20 R-next webpage UI section** — share-link page layout specified explicitly (chat primary, settings drawer secondary, artifacts panel persistent, upload/download integrated).
2. **Group I session profile schema (§11.3)** — passcode field added to schema (was implicit before; now explicit). Probably: `auth_method: "passcode" | "token_only" | "identity_bound"` with passcode as default.
3. **Multi-corpus selection mechanism in session profile** — `corpus_access_list` already supports multiple corpora. The UI's multi-select toggle for search scoping needs a corresponding session-time field: probably a `currently_active_corpus_subset` or similar that the user can set within their permitted access list.
4. **Document upload integration** — per-share-token `document_ingestion_permission` flag (already in session profile §11.4) drives whether the upload button surfaces.
5. **Artifacts panel** — new UI primitive for share-link sessions; ephemeral (session-lifetime), references to agent-produced or agent-delivered content. Couples to V1.5.1 §10 access_path machinery (artifacts are pointers, not copies).
6. **UI complexity tier coupling (Group L)** — share-link sessions default to `tier=minimal`, which means the settings drawer surfaces only the corpus selector + upload toggle + auth indicator. Advanced settings (re-extraction triggers, prompt iteration controls, calibration ledger) are excluded at minimal tier. The architect's "more is better for me; defaults for sharing" principle is enforced via tier.

### Things this note does NOT address

The note specifies the share-link page UI but does NOT yet address:

- **Webpage hosting model:** Where does the webpage actually live? Tailscale-routed endpoint on the host machine? Cloudflare-tunnel pattern? Local web server on the host? V1.6 needs to specify.
- **Session lifecycle UI:** What does the user see when their session expires (per `expires_after` field)? What does the user see when the host machine is offline?
- **Concurrent session handling:** Multiple users hit the same share link simultaneously — does each get an independent session? Yes (per architect's intent), but the page rendering and host-side resource handling needs spec.
- **Browser compatibility floor:** What browsers are supported? V1.6 should specify a minimum (probably modern Chrome/Safari/Firefox).
- **Mobile rendering:** The architect's M4 Pro is desktop-first, but firm attorneys may hit share-links from mobile. Responsive design specification needed in DOC20 R-next.

These are all V1.6 spec drafting concerns that this note flags for explicit treatment.

---

## (Future notes will be appended here as they arrive)

Format for future notes:
- Note number, dated
- Source (architect / reviewer / observation)
- What's specified
- Why it matters
- Spec impacts
- Things not yet addressed