gh-claude/guildhall
SHA256
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
9 commits 2 branches 0 tags 281 KiB
Commit graph

3 commits

Author SHA256 Message Date
Tyler J King
c0959a5376 feat(guildhall): minimum viable guildhall — OIDC, guilds, schematics, members 
Implements the full founding-guild onboarding stack across four phases:

Phase A — Keycloak OIDC auth pipeline (oidcc) + guild registration with
ceremony-engine approval (SingleApproval, hub operator approves via gRPC).
Phase B — Founding schematic templates (MSP/ISV/NSP TOML), gRPC clients
for ceremony-service and ffc-schematic-server, schematic fork/bind/realize
LiveView with DB audit trail in guild_schematics.
Phase C — RealizationPoller GenServer polling realization status every 5s,
PubSub broadcast, live realization dashboard showing 7 reconciler sections.
Phase D — Self-service member onboarding (join request → guild master
approval via ceremony), member management LiveView, auto-create guild
master on guild approval via Ecto.Multi transaction.

Includes K8s manifests for ceremony-service (port 50053) and
ffc-schematic-server (port 9091) as ClusterIP services, plus updated
guildhall deployment with OIDC and gRPC service URL env vars.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Signed-off-by: Tyler J King <tking@guildhouse.dev>
 2026-05-15 15:03:50 -04:00
Tyler J King
48a7495ef5 feat(orchestrator): CeremonyOrchestrator + Chronicle.Consumer stubs 
CeremonyOrchestrator: GenServer providing a PubSub broadcast
interface for ceremony status changes. LiveView subscribes to
these broadcasts for real-time updates. A K8s CRD watcher will
feed events into this in a future sprint; for now the init log
makes the stub state explicit.

Chronicle.Consumer: stub for the Ops DB projector that will
consume Chronicle events and hydrate the Ecto tables. Projector
design (idempotent, checkpointed, catch-up on restart) per
DESIGN-OPS-DB-CHAIN-OF-CUSTODY-0001 §2.5.

Both modules document the orchestrator/engine distinction:
guildhall orchestrates, substrate decides.

Both are now supervised by their respective application trees
(Guildhall.Orchestrator.Supervisor, Guildhall.Chronicle.Supervisor).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Tyler J King <tking@guildhouse.dev>
 2026-04-18 07:21:45 -04:00
Tyler J King
4e22729bef feat: scaffold guildhall Elixir umbrella 
Ceremony orchestrator + governance UI layer over substrate CRDs.
guildhall presents and coordinates; substrate decides and enforces.

Apps:
- guildhall_web: Phoenix LiveView UI for ceremony workflows,
  Forge visualization, posture dashboards
- guildhall_orchestrator: watches CeremonyRequest CRDs, notifies
  witnesses, collects signatures, tracks ceremony lifecycle
- guildhall_ops_db: Ecto schemas for the five Ops DB tables
  (per DESIGN-OPS-DB-CHAIN-OF-CUSTODY-0001)
- guildhall_graph_bridge: Microsoft Graph API reconciler (stub)
- guildhall_chronicle: Chronicle event consumer + Ops DB
  projector (stub)

Naming: guildhall components are orchestrators (workflow),
NOT engines (enforcement). The ceremony engine is a substrate
K8s operator. guildhall coordinates humans around CRDs.

Elixir 1.17.3 / OTP 27 / Phoenix 1.8.5. SHA-256 git repo.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Tyler J King <tking@guildhouse.dev>
 2026-04-18 07:09:20 -04:00