01 WebMCP — desktop jasny · owner (klient) · 1440×1280 · zgięcie 810

Packs

modules.json → aios-webmcp.packs
tylko operator
site-nav 4 R
wyszukiwanie treści, artykuł, cluster, autor — 4 narzędzia R
w registry
contact 1 W
submit_lead — 1 narzędzie W (wymaga consent; stub bez backendu formularza)
w registry
content-credentials 1 R
get_image_credentials — provenance obrazów z sidecar ingestu
w registry
commerce 0 · C
kill-gate Discoveryprofiles: []. Odblokuje operator po werdykcie (katalog + inventory + fulfillment). werdykt

Registry

tools.json · v0.1.0
embedded R-tier payload: 4 artykułów · 2 autorów · 3 stron
Wszystkie 6 R 5 W 1 C 0 R read W write C commerce
name · pack · requiredtierOpisinputSchema
search_contentsite-nav · req: query
RSearch published articles and pages by keyword 1 pole
get_articlesite-nav · req: slug
RGet a published article by slug 1 pole
list_clustersite-nav · req: cluster
RList articles in a content cluster 1 pole
get_authorsite-nav · req: slug
RGet author profile by slug 1 pole
submit_leadcontact · req: email, consent
WSubmit a contact lead (requires consent; stub when no form backend) 4 pola
{ "type": "object",
  "properties": { "email": string, "name": string, "message": string, "consent": boolean },
  "required": ["email", "consent"] }
get_image_credentialscontent-credentials · req: —
RReturn content credentials / provenance for site images 1 pole
Narzędzia R odpowiadają z payloadu osadzonego w HTML (bez sieci). W idzie POST-em do /api/webmcp. C nie istnieje bez profilu commerce.tools.json · 18,4 kB
02 WebMCP — desktop operator · operator · data-theme=operator · 1440×1280

Packs

modules.json → aios-webmcp.packs
przełącza operator
site-nav 4 R
wyszukiwanie treści, artykuł, cluster, autor — 4 narzędzia R
w registry
contact 1 W
submit_lead — 1 narzędzie W (wymaga consent; stub bez backendu formularza)
w registry
content-credentials 1 R
get_image_credentials — provenance obrazów z sidecar ingestu
w registry
commerce 0 · C
kill-gate Discoveryprofiles: []. Odblokuje operator po werdykcie (katalog + inventory + fulfillment). werdykt

Registry

tools.json · v0.1.0
embedded R-tier payload: 4 artykułów · 2 autorów · 3 stron
Wszystkie 6 R 5 W 1 C 0 R read W write C commerce
name · pack · requiredtierOpisinputSchema
search_contentsite-nav · req: query
RSearch published articles and pages by keyword 1 pole
get_articlesite-nav · req: slug
RGet a published article by slug 1 pole
list_clustersite-nav · req: cluster
RList articles in a content cluster 1 pole
get_authorsite-nav · req: slug
RGet author profile by slug 1 pole
submit_leadcontact · req: email, consent
WSubmit a contact lead (requires consent; stub when no form backend) 4 pola
{ "type": "object",
  "properties": { "email": string, "name": string, "message": string, "consent": boolean },
  "required": ["email", "consent"] }
get_image_credentialscontent-credentials · req: —
RReturn content credentials / provenance for site images 1 pole
Narzędzia R odpowiadają z payloadu osadzonego w HTML (bez sieci). W idzie POST-em do /api/webmcp. C nie istnieje bez profilu commerce.tools.json · 18,4 kB
03 WebMCP — stany · loading · empty · error · blocked · 1440×780
Loading skeleton registry · shimmer 1200 ms · bez opacity
Empty plugin bez registry · checklist runbooka, nie ilustracja

Registry jeszcze nie istnieje

Plugin aios-webmcp jest włączony, ale nie było jeszcze buildu — bridge i endpoint nie mają czego serwować.

  1. Włącz aios-webmcp w modules.json Moduły
  2. Wybierz packi (domyślnie site-nav · contact · content-credentials) DEFAULT_PACKS
  3. Uruchom build — krok data wygeneruje tools.json i payload R npm run build
  4. Sprawdź bridge: check-webmcp-html dist/ musi dać PASS CI guard
Pack commerce pozostaje zablokowany niezależnie od buildu (kill-gate Discovery). Moduły
Error bridge check FAIL · CI guard czerwony · log + retry
check-webmcp-html FAIL bridge nieobecny

Żaden plik HTML w dist/ nie zawiera modelContext ani registerTool. Najczęstsza przyczyna: integracja aios-webmcp nie została dodana do astro.config po zmianie slotów. Endpoint może dalej odpowiadać 200 — bridge to osobna warstwa.

$ node scripts/check-webmcp-html.mjs dist
[check-webmcp-html] scanned 11 HTML files
check-webmcp-html FAIL: no HTML contains modelContext or registerTool
exit 1 · 0,3 s
kopiuj log astro.config.mjs
Blocked kill-gate + endpoint bez klucza · BLOCKED, nie „partial done”

Pack commerce zablokowany BLOCKEDUNVERIFIED

Kill-gate Discovery: profiles: []. Narzędzia C (koszyk, checkout, Stripe) nie trafiają do registry i nie pojawią się w Playground. Odblokowanie wymaga werdyktu Discovery (katalog + inventory + fulfillment) i wpisu profiles: ["commerce"] przez operatora — nie przez ten panel.

Endpoint W-tier bez AION_TENANT_KEY BLOCKED

W trybie aion POST-y W są meterowane przez hub (usage_url). Bez klucza tenanta endpoint zwraca 401 dla W; R z payloadu HTML działa dalej. Nie pokazujemy „częściowo działa” — sekcja Endpoint jest oznaczona BLOCKED do czasu ustawienia klucza.

POST /api/webmcp 401 · missing tenant key
05 WebMCP — spec · decyzje, badge vs cisza, LIVE/UNVERIFIED, komponenty

Decyzje projektowe — WebMCP

  1. Packs nad Registry, bo pack jest przyczyną, narzędzie skutkiem. Cztery toggle-rows (trzy aktywne + commerce z KillGateLock) mieszczą się nad zgięciem razem z paskiem i nagłówkiem registry.
  2. Tier R/W/C jako jednoliterowy kwadrat mono, nie kolorowy badge: R neutralny, W z obrysem --blue (idzie w sieć), C przerywany (nie istnieje). Kolor statusu (ok/warn/critical) nie jest używany do tieru — tier to typ, nie stan.
  3. Badge „embedded R-tier payload” stoi w nagłówku Registry, bo dotyczy całego pliku tools.json, nie jednego wiersza. Liczby artykułów/autorów/stron pochodzą z registry.data.
  4. inputSchema rozwijane w wierszu (jeden otwarty: submit_lead, bo jako jedyny W ma pole consent). Otwarty wiersz zmienia tło na --surface-2, bez ramki i bez drawera.
  5. Bridge check to lista czterech dowodów z linkiem do pliku w dist/, nie jeden zielony kafel. Zielony tylko z komendą check-webmcp-html PASS i czasem.
  6. Playground wywołuje wyłącznie R z payloadu osadzonego w HTML (bez sieci); W tylko z jawnym consent i pod logiem POST-ów; C nieosiągalne. Odpowiedź JSON w mono z podświetleniem kluczy --blue i stringów --teal.

Co jest badge'em, co ciszą

SygnałFormaDowód
Pack aktywnytoggle on + cisza „w registry · LIVE”registry.packs[]
Pack commerce.kill-lock: kłódka + powód + link do werdyktu; toggle przerywanyprofiles: []
Bridge PASSStatusTile ok + 4 punkty check-list + LIVE · 03:02check-webmcp-html PASS
Bridge FAILerror-panel z logiem i retry; CI guard w Build & Deploy czerwonyexit 1
Endpoint 200StatusTile ok + wiersz GET; POST 400 = warn inline na kodzieGET /api/webmcp
Endpoint 401 (brak klucza)blocked-banner „BLOCKED · LIVE”AION_TENANT_KEY unset
Registry nieistniejąceempty-checklist 4 krokówbrak tools.json

Dane LIVE / UNVERIFIED na planszy

ElementŹródłoEtykieta
nazwy narzędzi, packi, tiery, opisy, inputSchemapackages/webmcp/src/tool-registry-gen.tsLIVE
DEFAULT_PACKS, wersja registry 0.1.0ten sam plikLIVE
komunikaty bridge check (PASS/FAIL)scripts/check-webmcp-html.mjsLIVE
feature-detect document.modelContext || navigator.modelContextpackages/webmcp/src/bridge-inline.jsLIVE
liczby payloadu (4/2/3), rozmiar 18,4 kB, czasy, log POST-ówsnapshot planszyUNVERIFIED
id skryptu aios-webmcp-data, cluster sprzedaz-uslugpropozycjaUNVERIFIED

Tokeny — decyzja koloru akcentu

--accent-op = ciemny miód (jasny motyw) / jasne złoto (operator). Różni się od --warn (ochra) jasnością, nie tylko odcieniem — po desaturacji primary CTA i badge warn nie zlewają się. --accent-cl = głęboki granat (jasny) / jasny błękit (operator), różny od --teal. --purple zadeklarowany, nieużyty.

--accent-op --warn --accent-cl --teal --ok --critical --blue --muted

Użycie --accent na planszy: aktywna pozycja menu systemu, primary CTA, focus ring. Nic więcej. Aktywna zakładka i toggle „on” idą przez --text, żeby akcent nie konkurował ze statusem.

Shell — AIONLINE-CONTRACT

Menu systemu 244 px po lewej (brand „AIOS Admin”, tenant switcher tylko dla operatora, 12 pozycji IA §1, stopka: ModeBadge + build). AionLine 56 px po prawej: systemy Hub · Discovery · Panel · Create, inbox ekosystemu, obecność, profil, wyloguj, rozsuń. Topbar produktu bez dzwonka i profilu. Commerce w menu z kłódką i tooltipem „kill-gate Discovery”.

Board 01 = rola client/owner (jasny, tenant statyczny, brak akcji operatorskich). Board 02 = operator (data-theme="operator", switcher tenantów, pełne akcje). Ta sama IA w obu — różnią się tylko uprawnieniami.

Komponenty użyte (BRIEF §5) i hierarchia

.status-tile ×4 · .tbl (wariant .gate-table dla registry, z wierszem rozwijanym) · .tabs · .kill-lock (pack commerce + menu) · .event-stream (ostatnie POST-y) · .mode-badge · .skeleton · .empty-checklist · .blocked-banner ×2. Nieużyte celowo: .conceal (klucz tenanta żyje w Ustawieniach), .chart-bars (POST-y/dzień należą do Usage), .diff-panel, .drawer (schema rozwija się w wierszu).

Hierarchia: lewa kolumna = konfiguracja i jej skutek (Packs → Registry), prawa = dowody i test (Bridge → Endpoint → Playground). Nad zgięciem: pasek, Packs, nagłówek Registry z badge'em payloadu, Bridge check. Kolor statusu wyłącznie na StatusTile, kodzie POST 400 i banerach; tier bez koloru stanu. Obrys 1 px tylko na wierszach, toggle'ach, polach, kwadratach tieru.