P0 product discovery: primaerer Nutzer und falsifizierbare Wert-Entscheidung fuer die Offline-Laufzeit (Register D2)

[marcohost33-maker]

Execution artifact

Research protocol: docs/research/PRODUCT_DISCOVERY_PROTOCOL.md in PR #17.

Problem

APP-01 has a strong security/architecture foundation but no verified primary user, differentiated top task or evidence that a public MCP browser client is the right first product form.

Implementation activity is not product evidence. A controlled internal client, gateway-mediated application, integration into an existing host, pivot or stop are valid outcomes.

Pre-work

Before the first evaluative session, commit:

• one candidate primary persona and anti-persona;
• one bounded read-only task;
• current alternative/workaround;
• target task time and success rate;
• consent-comprehension threshold;
• explicit falsification and go/pivot/stop criteria.

Method

Problem evidence

• 5–8 structured interviews or documented proxy evaluations.
• Ask about recent observed work, frequency, consequence and alternatives.
• Record raw observations separately from interpretation.
• Capture non-adoption and contradictory evidence.

Task/consent prototype

Mock-backed and non-production:

• endpoint/operator identity;
• data/privacy boundary;
• untrusted capabilities;
• one visible read-only request;
• explicit approval/rejection;
• timeout, cancel and normalized errors;
• bounded result and clear-session behavior.

Comprehension measures

Without showing the consent text again, verify the participant can state:

1. which endpoint/operator receives data;
2. which arguments/data are sent;
3. which capability and duration are approved;
4. how to cancel and clear the session.

Architecture fit

Feed evidence into #13/ADR-003:

• controlled versus arbitrary endpoint need;
• direct browser CORS feasibility;
• auth/credential requirements;
• data categories and operator responsibilities;
• support and incident expectations.

Exit criteria

• one selected persona and anti-persona;
• one selected read-only task and explicit non-goals;
• pre-registered thresholds compared with observed results;
• comparison against existing MCP clients/hosts and current workaround;
• negative evidence included;
• endpoint/deployment implications linked to P0 ADR-003: endpoint trust, browser transport, CORS and deployment topology #13;
• dated go, pivot or stop decision;
• next experiment and owner.

Gate

No runtime feature expansion and no closure of this issue without linked evidence. The chosen task must be compatible with an endpoint/deployment model that can pass APP-01 security, privacy, accessibility and operational gates.

[marcohost33-maker]

Triage 2026-07-17 — verdict: STILL-VALID · critical-path #1

Under the ADR-008 standalone reframe (local branch vero/2026-07-16-standalone-reframe-and-report, unpushed during the CI/budget freeze), browser is a standalone native offline runtime; nigin-engine/browser-nigin are separate repos (knowledge-transfer only, no build/runtime dependency); MCP is browser-internal, optional and off the critical path. None of that weakens this issue — it strengthens it: product-discovery evidence is the precondition for everything.

Position: top of the critical path — #14 → #30 → #23 → #24 → first T1 offline slice. #4, #7, #23, #24, #30 all gate on the persona/task/thresholds this issue pre-registers.

Next concrete action: commit the pre-registered persona/anti-persona, one bounded read-only task, and the falsification/go-pivot-stop thresholds (docs/research/PRODUCT_DISCOVERY_PROTOCOL.md) before the first evaluative session. No fabrication of evidence; negative evidence must be retained. Priority: P0.

[marcohost33-maker]

Critical-path correction (self-review): the chain I posted earlier over-serialized the two spikes. Corrected dependency graph:

#14 (product discovery) → #30 (offline-mode taxonomy M1–M4)
                               ├── #24  (M1 signed-package spike)     ┐ parallel,
                               └── #23  (M2/M3 runtime spike)         ┘ both gated on #30
                                        → first T1 end-to-end slice

#23 and #24 are parallel siblings both consuming #30, not sequential — matching the #30 fork (M1 requirements → #24, M2/M3 → #23) and the issue bodies (#23 "Depends on #30"; #24 "owns M1 from #30"; neither depends on the other). The linear #23 → #24 ordering was wrong.

The surviving T1 app-shell / UI-stack decision (which typed UI stack under CSP) remains owned by the reopened #7 until re-homed.

[marcohost33-maker]

Umgewidmet am 2026-08-28

Diese Aufgabe wurde am 2026-07-10 erstellt. Drei Tage spaeter, am 2026-07-13,
hat #21 das Produkt neu gerahmt: aus einem oeffentlichen MCP-Web-Client wurde
eine native, offline-faehige Laufzeit-Umgebung. Die Aufgabe blieb seither
unveraendert stehen und beschreibt ein Produkt, das es so nicht mehr geben soll.

Die Frage ueberlebt die Neurahmung, ihr Gegenstand nicht. Wer der erste
Nutzer ist und woran man merkt, dass die Antwort falsch war, bleibt richtig
gestellt -- nur nicht mehr fuer einen MCP-Client.

Was jetzt gilt

Der Registereintrag D2 in docs/OPEN_DECISIONS.md fuehrt genau diese Frage
als OPEN / P0. Verlangt sind: eine Persona und eine Anti-Persona, eine
gebundene Offline-Aufgabe, ein manueller Einspielweg, messbare Erfolgs-,
Zustimmungs- und Wiederherstellungs-Kriterien -- und ein ausdrueckliches
Ergebnis weiter / schwenken / aufhoeren.

Es ist der einzige offene Punkt des Repositoriums, an dem aufhoeren eine
zulaessige Antwort ist. Jeder andere Aufwand lohnt sich nur, wenn jemand das
Ergebnis benutzt.

Was ausdruecklich NICHT mehr gilt

Die Frage aus dem urspruenglichen Rumpf, ob ein oeffentlicher MCP-Browser-Client
die richtige erste Produktform sei, ist beantwortet: Registereintrag D1 steht
auf RESOLVED -- MCP ist intern, optional und nicht auf der T1-Kernlinie. Der
Abschnitt "Architecture fit" mit dem Verweis auf #13/ADR-003 ist damit
gegenstandslos.

Vorschlag zur Antwort, vorgelegt am 2026-08-28

Eine Entscheidungsvorlage liegt unter
docs/reports/2026-08-28_P0_ENTSCHEIDUNGSVORLAGEN.md, Punkt V10. Empfohlen wird
dort der Eigentuemer selbst als primaerer Nutzer -- fuer T1 (eigene, selbst
signierte Programme) ist das sachlich richtig, und es ist sofort beantwortbar.
Die Anti-Persona waere dann jemand, der beliebige fremde Webseiten offline lesen
will: genau das, was T1 nicht kann.

Der urspruengliche Rumpf bleibt unveraendert stehen -- er zeigt, was am
2026-07-10 beabsichtigt war.