Reconcile FAAS authority and Hermes governed-worker contract

[erikhinla]

Purpose

Lock the architecture decision before implementing a Hermes worker adapter: FAAS owns governed execution and proof; Hermes is a standalone FAAS-governed canon-and-learning execution worker, not the runtime governor.

Locked Host Roles

• Hetzner VPS: staging and the first FAAS/Hermes proving-run environment.
• Hostinger VPS: production destination only after successful staging evidence, rollback readiness, and Erik's explicit promotion approval.

Changes

• Updates config/hermes.yaml to encode FAAS/Hermes/operator authority boundaries and planned adapter guardrails.
• Rewrites Hermes overview/runtime rules to use governed-worker language and require FAAS proof/write-back.
• Reconciles DEPLOYMENT.md with the services actually present in current docker-compose.yml and adds the Hetzner-to-Hostinger promotion gate.
• Updates the domain/operations map to record Hostinger production, Hetzner staging, TBTX/BBAI remaining design/deployment work, and BBM as gated downstream activation.
• Adds docs/architecture/FAAS_HERMES_WORKER_CONTRACT.md, covering API boundary, lifecycle, atomic claim/idempotency, risk/review separation, security boundary, host roles, and first TBTX proving task.
• Adds an amendment explicitly superseding stale runtime-governor and deployment-state claims in the earlier audit.

Ground Truth Correction

Current docker-compose.yml defines the FAAS control-plane stack (flow-gateway, bizbrain-lite, notion-flow-bridge, dashboard, optional Discord bot, Redis, Postgres). It does not yet define Hermes, OpenClaw, or Agent Zero worker services. This PR intentionally makes no claim that those workers are presently deployed.

Next Implementation PR

After review, implement/reconcile the Postgres-backed job API contract and atomic claim lifecycle required by the Hermes adapter. Do not add the Hermes worker container until the state/routing/write-back contract is executable.

Verification

Documentation/config reconciliation only; no runtime code changed and no deployment was performed. The branch contains seven changed files against main.

Follow-Up Before Merge

docs/HERMES_SUPER_PROMPT_EXECUTION_AUDIT.md remains a historical document containing stale language; this PR adds a superseding amendment. An inline rewrite or explicit historical banner should be decided before treating the old audit as current authority.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
flow-state	Ready	Preview, Comment	May 26, 2026 7:27pm

[gemini-code-assist]

Code Review

This pull request refactors the documentation and configuration files to establish a clear architectural boundary between the FLOW Agent Architected Schemas (FAAS) control plane and the planned standalone Hermes execution worker. It introduces a formal worker contract, runtime rules, and an audit amendment to correct prior deployment claims. The review feedback highlights three key areas for improvement: clarifying the construction of isolated workspace paths relative to base memory paths, resolving a validation mismatch where the existing EnvelopeValidationService does not yet support the newly introduced low and medium risk tiers, and specifying the exact API response or adapter behavior when a replay request is received for an actively claimed task.

[gemini-code-assist]

To prevent different adapter or worker implementations from using conflicting directory structures, please clarify how the isolated workspace path is constructed relative to the base memory_paths defined in config/hermes.yaml (e.g., whether they should append /<task_id>/attempt_<attempt>/ to the base paths).

Suggested change

	- Each Hermes task uses an isolated workspace keyed by `task_id` and attempt.
	- Each Hermes task uses an isolated workspace keyed by task_id and attempt (e.g., appending /task_id/attempt_attempt/ to the base memory_paths defined in config/hermes.yaml).

[gemini-code-assist]

Note that the current EnvelopeValidationService in services/bizbrain_lite/app/services/envelope_validation_service.py strictly validates risk_tier against ['reputation', 'time_loss', 'downtime_security_money'] (lines 73, 130). If a client submits a task envelope with the new low or medium risk tiers, validation will fail immediately. When implementing the reconciliation in Step 3 of the gates, ensure the validation service is updated to support or map these new tiers.

[gemini-code-assist]

For the idempotency rule, please specify the expected adapter behavior or API response when a replay request is received for an actively claimed/in-progress task (e.g., returning a 409 Conflict, a specific status payload, or blocking/polling). This ensures consistent client handling during concurrent or duplicate submissions.

Suggested change

	Every adapter-mediated Hermes task uses `task_id` as its idempotency key. An
	adapter must atomically claim a queued task before invoking Hermes. A completed
	task returns its existing artifact on replay; an actively claimed task is not
	executed twice.
	Every adapter-mediated Hermes task uses task_id as its idempotency key. An
	adapter must atomically claim a queued task before invoking Hermes. A completed
	task returns its existing artifact on replay; an actively claimed task is not
	executed twice and returns an in-progress status or conflict error.