SMAJOR
Cloudflare facade · Akash runtime · S25 mesh · clients
Portail client

Donner aux clients une interface propre, pas le chaos du backend.

Le portail client doit couvrir demandes de service, devis, facturation, suivi et communication sans exposer la complexite du mesh.

MVP

Demandes et suivi

Creer un dossier, suivre un service, recuperer un devis, consulter facture et etat du contrat.

S25

Automatisation metier

Les relances, le routage et les escalades doivent etre portes par S25, pas par du bricolage front-end.

Suite

Historique client

A terme: historique de services, photos terrain, documents signes et rappels automatiques.

Live S25

Panneaux operations

Le shell lit le cockpit public et affiche la realite du mesh sans inventer un faux statut front-end.

Status

MESH_READY

S25 en ligne. Pipeline MESH_READY. Mesh actif avec 5 agents online et 14 mission(s). Tunnel offline.

Agents online 5
Missions actives 14
Signal READY
Tunnel offline
Missions

Track smajor.org activation and align Gemini Orchestrator plus TRINITY on the official operating model: facade on Cloudflare, backend on S25 mesh, MERLIN via MCP, Home Assistant lateral only.

Agent recommande: perplexity. Priorite: critical.

Actives 14
Historique 3
Top target COMET
Top type infra_monitoring
Mesh

ARKON · COMET · MERLIN · ORACLE

Mission queued for COMET: Track smajor.org activation and align Gemini Orchestrator plus TRINITY on the official operating model: facade on Cloudflare, backend on S25 mesh, MERLIN via MCP, Home Assistant lateral only.

BTC $70621
ETH $2069
Confiance 50
HA lateral linked
Resilience

Facade et mesh alignes

Le domaine public, le cockpit Akash et MERLIN MCP repondent dans le meme modele operationnel.

Facade Cloudflare
Runtime Akash
Backend S25
Mode Mesh-first
Workbench

Portail client cible

On prepare une interface simple pour le client, pendant que S25 garde l'orchestration, les relances et le routage.

Demandes
  • Nouvelle demande de service.
  • Suivi de dossier et statut chantier.
  • Canal de contact propre avec historique.
Documents
  • Devis a signer.
  • Factures et paiements.
  • Photos et preuves de service.
Automations
  • Relances automatiques par S25.
  • Tri des urgences selon le service.
  • Passage propre vers admin et staff.
Industrial kit

Client dossier blueprint

Ce schema sert de contrat de construction entre le front, api.smajor.org et le backend S25.

Records
client_accountservice_siteservice_requestquotework_orderinvoicepayment_status
Pipeline
  1. lead_received
  2. qualified
  3. quote_sent
  4. approved
  5. scheduled
  6. in_service
  7. completed
  8. invoiced
  9. paid
Automations
  • S25 route une demande selon service, urgence et zone.
  • TRINITY cree une mission si un dossier bloque ou derape.
  • COMET alimente les alertes de suivi et les escalades externes.
Administration

Client access chain

Chaque client et contact doit etre rattache a une organisation, puis recevoir seulement les services achetes.

Roles
client_orgclient_contact
Doctrine
  • Chaque personne ou organisation existe comme identite gerable dans le systeme.
  • Chaque identite recoit un role, un scope et des services actives.
  • Aucun acces implicite: tout acces doit etre assigne puis revele dans l'admin.
Activation flow
  1. identity_created
  2. linked_to_org
  3. role_assigned
  4. services_enabled
  5. credentials_issued
  6. portal_access_live
Services enabled
client_portalbilling_accesssnow_opsexcavation_opsai_services
Core records
  • identity
  • organization
  • membership
  • service_entitlement
  • credential_state
  • policy_scope
  • audit_log
Operational MVP

MVP registries

Ce sont les trois premiers registres a rendre operables pour transformer le shell en vrai systeme de gestion.

Clients registry MVP
  • client_id
  • organization_name
  • contact_name
  • contact_channel
  • create_client
  • activate_services
Jobs registry MVP
  • job_id
  • client_id
  • service_type
  • assigned_team
  • open_job
  • dispatch_team
Quotes and invoices registry MVP
  • quote_id
  • invoice_id
  • client_id
  • job_id
  • issue_quote
  • approve_quote
Role governance

Role governance model

Le systeme ne repose pas sur la confiance humaine. Il repose sur des roles, des scopes, des services actives et une chaine d'audit.

Role layers
Direction
founderexecutive_operatoroperator_adminidentity_controlfinance_approvalgovernanceagent_policies
External
client_ownerclient_contactvendor_managervendor_contactportal_accessdocument_exchangelimited_approvalsbilling_visibility
Doctrine
  • Le role passe avant la personne.
  • Chaque pouvoir doit venir d'un role publie et tracable.
  • Aucune elevation de privilege sans validation admin.
  • Les services actives sont limites par role, scope et portail.
  • La structure doit survivre a l'utilisateur.
Enforcement
  1. identity_created
  2. badge_template_selected
  3. role_template_selected
  4. scope_assigned
  5. services_enabled
  6. credentials_issued
  7. audit_watch_started
Identity binding
  • identity_id -> role_id -> badge_id -> scope_id -> service_entitlements
  • aucune fonction critique ne doit etre attachee a un nom fixe
  • si une personne change, on revoque la cle et on rattache une nouvelle identity_id au meme role_id
Badges
  • Major badge: founder|executive_operator|operator_admin
  • Employee badge: dispatcher|field_manager|staff_member|contractor
  • Client badge: client_owner|client_contact
  • Vendor badge: vendor_manager|vendor_contact
  • AI badge: trinity_orchestrator|merlin_validator|comet_watch|kimi_sensor
Identity registry

Identity registry model

Chaque acteur entre dans le systeme via une identite operable reliee a un role, un badge, un scope et un portail.

Records
  • identity_id
  • organization_id
  • identity_type
  • role_id
  • badge_id
  • scope_id
  • credential_state
  • portal_state
Activation
  • create_identity
  • bind_role_template
  • attach_scope
  • enable_services
  • issue_or_rotate_credential
Portal activation

Portal activation model

Un portail ne s'ouvre qu'apres la chaine complete d'activation identite-role-badge-scope.

Clients
  • identity_id
  • client_badge
  • client_contact
  • client_scope
  • billing_access
  • portal_live
Client form

Client intake form

Formulaire type pour faire entrer un client dans le systeme avec la bonne chaine d'identite et de service.

Identity
  • organization_name
  • contact_name
  • contact_email
  • contact_phone
Service
  • service_type
  • site_address
  • urgency_level
  • service_window
Commercial
  • quote_required
  • billing_contact
  • contract_mode
  • notes