Live setup remediation checklist

Date: 2026-06-25 Category: reports Status: Complete 🟢

Live setup remediation checklist

This checklist captures the concrete gaps between the current live Hermes setup under ~/.hermes/ and the intended design in this repo.

Goal

Bring the live multi-profile Hermes installation into closer operational alignment with hermes-multi-agent-workflow.

Current high-level status

Aligned enough to operate:

• emil-workflow board exists and is the current board.
• Gateway is running, including --profile orchestrator gateway run.
• Core workflow profiles exist.
• hermes-lcm is enabled in the live setup.
• Workflow skills are installed.
• All 20 workflow profiles now reference the shared Infisical contract in SOUL.md.

Main gaps still remaining:

• stale kanban routing points to project-manager
• scout cron jobs are not registered
• several profiles drift from the repo baseline model deepseek-v4-flash
• Infisical runtime access still looks incomplete
• non-orchestrator runtime tool exposure is broader than the repo intends
• orchestrator still has delegation enabled, so profile-first behavior is partly policy-based

Priority 1 — fix stale kanban routing

Problem

Multiple live profile configs still contain:

kanban:
  orchestrator_profile: project-manager
  default_assignee: project-manager

But the workflow uses orchestrator, and /root/.hermes/profiles/project-manager does not exist.

Why this matters

This is the clearest live config inconsistency and can cause incorrect routing or confusing task assignment behavior.

Remediation

For every workflow profile that still references project-manager:

• set kanban.orchestrator_profile: orchestrator
• clear or intentionally set kanban.default_assignee
• prefer empty default_assignee unless there is a specific reason to force-assignee tasks

Verification

• search all workflow profile config.yaml files for project-manager
• verify no workflow profile still references it
• verify hermes kanban --board emil-workflow list still works normally

Priority 2 — register scout cron jobs

Problem

Live cron state currently has no jobs registered.

Why this matters

Without scout crons, the workflow is not running its intake stage automatically. The board and workers may exist, but the pipeline is not being fed.

Remediation

Create cron jobs for the scout sources defined in triage.yaml, using the intended scout profiles and schedules.

Expected scout coverage should include the repo's source profiles such as:

• build_scout
• infra_scout
• marketing_scout

Each scout job should:

• run on the correct profile
• load the correct scout skill
• create intake artifacts/tasks on emil-workflow
• deliver any human-facing output to the intended destination only if the workflow expects it

Verification

• hermes cron list shows the expected scout jobs
• trigger one scout manually and confirm it produces an intake artifact/task
• verify the resulting intake task lands on the correct board and routes to orchestrator

Priority 3 — normalize workflow profile models

Problem

The repo runbook expects every workflow profile to use:

provider: opencode-go
model: deepseek-v4-flash

But several live profiles currently use deepseek-v4-pro.

Why this matters

This is spec drift from the published workflow baseline. It may be intentional, but if the goal is adherence, it should be corrected or explicitly documented as a deliberate override.

Remediation

For workflow profiles:

• set provider to opencode-go where needed
• set default model to deepseek-v4-flash
• review fallback models for consistency with the workflow's cost/performance intent

If you intentionally keep some profiles on deepseek-v4-pro, document that as a conscious divergence in the runbook or local ops notes.

Verification

• inspect every workflow profile config.yaml
• confirm main provider/model matches the chosen standard
• optionally run one small smoke task per role after the change

Priority 4 — close the Infisical runtime-access gap

Problem

Profile instructions now point to Infisical correctly, but live runtime access still appears incomplete:

• no INFISICAL_* vars were present in the inspected shell environment
• /root/hermes-multi-agent-workflow/.env.multi-agent is missing
• repo notes still indicate the current client identity lacks access to the required homelab project

Why this matters

Instruction-level alignment is not enough; the profiles also need actual authenticated access to the secrets they depend on.

Remediation

• decide the canonical bootstrap path for live secrets exposure
• ensure the required Infisical client identity has access to the correct project(s)
• ensure the required values are available at runtime for the relevant profiles:
• INFISICAL_API_URL
• INFISICAL_PROJECT_ID
• INFISICAL_ENVIRONMENT
• INFISICAL_CLIENT_ID
• INFISICAL_CLIENT_SECRET
• verify the per-profile folder mapping from infisical-profile-bootstrap

Verification

• from at least one scout and one worker profile, perform a non-sensitive secret fetch smoke test
• confirm the fetch succeeds without printing secret values into logs or chat
• update docs/homelab/ACCESS_NEEDED.md if the access blocker is resolved

Priority 5 — tighten tool exposure on worker/scout profiles

Problem

Top-level toolsets are relatively reasonable, but platform_toolsets on many non-orchestrator profiles are still broad and include capabilities beyond the repo's minimum-toolset philosophy.

Why this matters

The repo's security posture expects tighter role boundaries:

• orchestrator: coordination + delivery
• scouts: web/search + kanban
• workers: only what they need for their stage

Broader runtime tool access weakens that separation.

Remediation

Review non-orchestrator profiles and remove unnecessary platform-level tool exposure where possible, especially from worker/scout profiles that do not need capabilities like:

• delegation
• computer_use
• browser
• code_execution
• tts
• unrelated media or messaging tools

Keep only what each role actually needs.

Verification

• inspect toolsets and platform_toolsets per workflow profile
• confirm worker/scout profiles have role-appropriate access only
• run a basic workflow smoke test after tightening permissions

Priority 6 — decide whether orchestrator should keep delegation

Problem

The orchestrator is now documented to be profile-first, but the live profile still includes the delegation toolset.

Why this matters

This means the guardrail is still mostly behavioral documentation rather than hard capability restriction.

Remediation

Choose one of these approaches:

1. Strict adherence mode
2. remove delegation from orchestrator tool access

3. force all specialist work through named workflow profiles

4. Pragmatic mode

5. keep delegation
6. explicitly document it as an emergency/ad-hoc escape hatch, not the default execution path

Verification

• inspect /root/.hermes/profiles/orchestrator/config.yaml
• confirm the chosen policy is reflected in both config and skill/docs
• run a small orchestration test and verify the orchestrator routes via named profiles

Suggested execution order

1. Fix project-manager drift in kanban config.
2. Register scout cron jobs.
3. Normalize models to deepseek-v4-flash or document intentional exceptions.
4. Restore/verify real Infisical access.
5. Tighten worker/scout tool exposure.
6. Make a final decision on orchestrator delegation.

Final verification pass

After remediation, run a full workflow sanity check:

• confirm emil-workflow is the active board
• confirm orchestrator gateway is running
• confirm scout cron jobs exist
• confirm no workflow profile still references project-manager
• confirm all intended profiles use the chosen provider/model baseline
• confirm Infisical secret fetch works for at least one scout and one worker profile
• confirm an intake item can be created and routed through the orchestrator

Definition of done

The live setup should be considered aligned enough when:

• all workflow routing points to orchestrator
• scout intake is automated by cron
• model choices are either normalized or explicitly documented as intentional
• Infisical access works in practice, not only in profile instructions
• non-orchestrator profiles have tighter role-appropriate tool access
• orchestrator routing behavior is consistent with the repo's profile-first design