Company Control Room

Slack Command Layer

Slack is the top approval and control layer for all Viewport entities. Every agent action that touches legal, financial, customer-facing, or destructive operations requires a Slack approval before execution. This page is generated from GitHub truth and live status.json.

PARTIAL FOUNDATION — honest status Record-first: Odoo record + evidence BEFORE Slack approval 3 approval-gate channels active 5-step gated protocol

Source & state

Sourcestatus.json · slack_odoo_operating_flows
RuntimeHermes v0.15.2
Last updated2026-06-05
Gate channels3 · all active
Protocol5 steps · record-first
System gate classesInfrastructure 4 · Business 4
EnforcementPARTIAL FOUNDATION

Approval-gate channels

These Slack channels are hardwired approval gates. No agent or human may complete a gated action without a thread approval in the correct channel.

Active

mlh-warranty-support

MLH warranty and support issues. Requires an Odoo Helpdesk ticket with attached evidence before any customer-facing, legal, or financial action.

Approval gateLegal / financial / customer-facing actions need explicit thread approval before execution.
Active

mlh-legacy-issues

Legacy MLH issue room. Same evidence-first and approval-gate policy. All findings must be logged in Odoo before action.

Approval gateEvidence attached in Odoo Helpdesk ticket required before any thread approval can be granted.
Active

mlg-finance-review

Finance approval room for MLG invoices, payments, and expense records. No send, no payment, no customer-facing action before channel approval.

Approval gateDraft in Odoo first. Post for review. Only execute after approval.

Slack ↔ Odoo operating flows

Live data from status.json · slack_odoo_operating_flows

AreaSlack channel / actionOdoo moduleFlow
Documents Approval thread/channel when legal or signature is needed Documents / document folder Document needed → Odoo document folder → Slack approval if legal/signature → sign only after approval
Helpdesk mlh-warranty-support mlh-legacy-issues Helpdesk MLH issue → Slack issue thread → Odoo helpdesk ticket → evidence attached → agent suggests next action → approval if legal/financial/customer-facing
Finance mlg-finance-review Accounting / Invoicing / Expenses Draft invoice/payment/expense → Slack finance review → Odoo record → approval before sending/payment/customer-facing action

Approval flow — how it works

Step-by-step protocol for any gated operation. Five gates, in order — no skipping, no reordering.

Non-negotiable · record-first rule

Odoo record + evidence BEFORE any Slack approval

Before anything is posted for approval, the action must be documented in the correct Odoo module — Helpdesk ticket, document folder, or finance record — with full evidence attached. The Slack post references the Odoo record ID and links the evidence. No record, no thread approval, no execution.

Odoo record Evidence attached Slack approval Execute
1 Identify the gated action

Agent or human identifies a gated action — legal, financial, customer-facing, destructive, DNS/billing, or any approval-class action.

2 Create Odoo record first

Document in the correct Odoo module (Helpdesk ticket, document folder, or finance record) with full evidence attached.

Record-first rule
3 Post to the correct Slack channel

Reference the Odoo record ID, describe the action, attach evidence link.

4 Wait for explicit approval

No action until a human (Sam or designated approver) replies with approval in the thread.

Hard stop · human gate
5 Execute and log outcome

Complete the action, then post the result back to the thread and update the Odoo record.

System-level approval gates (all agents)

These gate classes apply to every agent and human operator regardless of channel.

Infrastructure gates

  • Hermes / gateway / container restart
  • Docker stop / restart / delete / prune / volume / data mutation
  • DNS / registrar / billing changes
  • Secret rotation that can break live services

Business gates

  • Legal / finance / customer-facing actions
  • Production Odoo writes
  • Production Slack writes to external recipients
  • Any destructive or irreversible operation

GSD / RalphLoop active for GitHub Ops

Source: Issue #196 · gsd_ralphloop

Mode: GitHub issue → branch → artifact → validator → evidence → live status.
VPS runtime remains read-only/reconciliation until RuntimeContracts, backups, rollback, and approval gates exist.
GoalDefine in GitHub issue
SetupBranch + artifacts
Do / VerifyRun + test
EvidencePost to issue
Slack gateIf gated action

Known state / not overclaimed

Honest enforcement status — what is real today versus operating intent.

Partial Foundation

Slack channel/process mapping is visible, but full production Slack app enforcement still requires verified signing, idempotency, retries, rate limits, approval packets, and write policies. The channels and flows documented here reflect the operating intent — enforcement is being built incrementally.

Generated 2026-06-05T04:53:06.115685+00:00 · Source: viewport-corp/viewport-ops · No secrets embedded.
Viewport · migration · unified shell v1 (2026-06-10) · Data: /migration/status.json · Source: viewport-corp/viewport-os
Viewport · migration · unified shell v1 (2026-06-10) · Data: /migration/status.json · Source: viewport-corp/viewport-os
Viewport · migration · unified shell v1 (2026-06-10) · Data: /migration/status.json · Source: viewport-corp/viewport-os