Orchestration architecture

A process brain wrapped around delivery tools.

Krahnie/Hermes does not need to replace Krahnborn’s existing systems. It should connect them, enforce the delivery contract, and make each handoff easier for humans.

◉_◉
Intake

Classifies and scopes

⌁_⌁
Router

Finds client/repo/org

▣_▣
Builder

Branch + implementation

✓_✓
Reviewer

Checks standards

✎_✎
Docbot

Writes memory

Stack diagram

Team cockpit
SlackRequest threadsApprovalsStatusDiscord
Orchestration brain
Krahnie/HermesState machinePolicy checksIdentity mappingAgent roles
Work system
CardsEstimatesAssignmentsDue datesAcceptance criteria
Engineering lane
GitHubWorktreesFeature branchesPR templatesReviews
Salesforce lane
Connected orgsPartial sandboxChanged metadata deploysValidation
Knowledge lane
Client KBRunbooksFunctional docsTechnical docsLessons learned
A

Slack as delivery cockpit

Commands and buttons trigger safe actions: create card, start branch, summarize PR, deploy to partial, request validation, close with docs. Thread state becomes a readable activity log.

B

Identity and permission mapping

Slack users map to card owners, GitHub users, Salesforce permissions, and approval roles. Krahnie can prevent accidental actions by the wrong person or context.

C

Per-request isolation

Every request receives a dedicated branch and worktree so agent work, admin metadata changes, and human edits do not collide across clients or tasks.

D

PR templates as control surface

The PR is not just a diff. It is the checkpoint for intent, risk, test plan, changed metadata, rollback, screenshots, and documentation completeness.

E

CI/CD for Salesforce deltas

GitHub Actions deploy changed metadata to the connected partial sandbox and returns deployment evidence to Slack and the card.

F

Knowledge capture by default

Client-specific quirks, org routing rules, metadata dependencies, validation tricks, and reusable prompts become durable assets instead of lost context.

Guardrails built into the architecture

Human approvals for risky actions

Production deploys, destructive changes, permission/security changes, managed package updates, and client-visible communications should require explicit approval.

Client context boundaries

Krahnie should never mix repositories, org credentials, or client knowledge without explicit routing. Each action should display the active client/org/repo.

Auditability over magic

Automated decisions should leave traces: why an estimate was proposed, why files were changed, what tests ran, and what evidence supports validation.

Fallback to human-friendly operations

If CI, sandbox auth, or agent implementation fails, the process should degrade gracefully: preserve the card, branch, logs, and next recommended human action.