Preserve second-session architecture context

SESSION_NOTES.md

@@ -265,3 +265,86 @@ or distributed trust providers.
 The conceptual documents remain authoritative for broader intent:
 [`CONCEPT.md`](CONCEPT.md), [`ARCHITECTURE.md`](ARCHITECTURE.md), and
 [`DESIGN.md`](DESIGN.md).
+
+## Second-session correction and discussion
+
+The project reached a clean first milestone tagged `trustlab-v0.1.0`. During the
+next session we briefly began treating named or distributed trust providers as
+the immediate milestone. Sergeych correctly stopped this drift and restored the
+actual product hierarchy:
+
+1. Browsec is a Firefox-derived host for privileged security extensions.
+2. Browsec Trust API is the capability-controlled TLS security interface.
+3. Velvet Hammer is the built-in, irremovable root security extension; its
+   browser-neutral substance already exists in TrustLab.
+4. Third parties can later build continuity monitors, institutional policies,
+   historical databases, CT/revocation analysers, and community systems.
+5. Distributed trust is a later extension family, not a prerequisite for the
+   browser platform.
+
+Two platform requirements were then underlined and added to the authoritative
+documents:
+
+- A privileged security extension needs isolated, durable, general-purpose
+  storage for any observations, indexes, historical data, intermediate state,
+  user annotations, or other information required by its security function.
+  This is broader than the structured trust-policy database. Storage remains
+  capability-controlled, quota-visible, inspectable, exportable, deletable,
+  migratable, and isolated from other extensions.
+- The browser needs an unforgeable user action, provisionally named **Record
+  security concern**, that starts evidence capture and opens Velvet Hammer on a
+  conventionally successful or failed connection. It records concern and facts;
+  it does not prejudge the resource as insecure. Captures exclude page content,
+  credentials, cookies, authorization headers, private keys, and TLS secrets.
+
+These corrections were committed as `55f614f` (*Restore security extension
+platform as primary goal*) and pushed to `origin/main`.
+
+### Distributed-trust exploration, deliberately deferred
+
+Before the priority correction, we began exploring what users might benefit
+from in a future distributed-trust extension. A neutral public interview guide
+was saved as [`USER_RESEARCH.md`](USER_RESEARCH.md). It asks what people want,
+tolerate, fear, and would immediately reject without assuming that communities
+are good or conventional authorities are bad.
+
+Sergeych also described firsthand experience as Cybiko's software director from
+the beginning through the final production model. Relevant experience—not an
+architecture to copy—included:
+
+- one or two RF discovery channels plus a region-dependent data-channel band;
+- compressed public-profile pings, locally calculated time slots, and a
+  four-dimensional space/time/frequency view of transmission opportunity;
+- production-assigned unique device IDs and packet origin/serial idempotency;
+- TTL-limited multi-hop forwarding with battery, foreground activity, traffic
+  density, link quality, ACK/reply overhearing, and neighbor density considered;
+- direct observations kept distinct from second-hand one-to-two-hop maps;
+- age-based topology expiry after missed discovery pings;
+- distance-biased delayed relaying, where farther receivers could forward first
+  and nearer candidates suppress duplicates after overhearing;
+- an early repeat of an important packet acting as a request that waiting relay
+  candidates transmit sooner;
+- adaptive frequency choice based on SNR, BER, and delivery history;
+- Reed–Solomon coding for operation near the permitted noise floor;
+- optional PC/Internet-connected cells acting as smarter rendezvous and
+  store-and-forward bridges for dial-up/NAT-era networks;
+- a memorable testing failure: a one-character Atmel-code error broke the exact
+  two-device topology, which was absent from a development site containing
+  dozens of devices.
+
+The conclusion was not to transplant a 25-year-old mesh design. Its valuable
+lesson is the experience of deriving a new architecture from goals, physical
+constraints, failure modes, local observations, ageing, and feedback rather
+than beginning with an attractive algorithm.
+
+### Current resume point
+
+Do not implement distributed trust next. Continue from the Firefox host seam:
+
+1. Select a Firefox revision for the privileged-extension experiment.
+2. Map NSS/PSM success and failure into immutable `TlsFacts`.
+3. Define privileged extension identity, capability grants, protected UI, and
+   isolated evidence storage.
+4. Define the browser-produced manual security-concern capture record.
+5. Connect Velvet Hammer and demonstrate failed navigation, informed decision,
+   durable scoped policy, and a fresh enforced retry.