Techcle Wiki

Managers

5 min read

Manager Operating Standards — CascadeGuard

This file captures shared operational standards for all managers (CEO, CTO, PO, CMO). It supplements the SDLC and each manager’s individual AGENTS.md. If this file conflicts with AGENTS.md, AGENTS.md takes precedence.

All managers must read this file. Reference it in your AGENTS.md under ## References.

Comment Standards

All managers must follow comment-efficiency.md for formatting. Additionally:

No cross-task summaries on issue threads. Every issue comment must contain ONLY information relevant to that specific issue. Never post heartbeat summaries, operational scan results, or status updates for other tasks in an issue comment.

  • ✅ Post a brief status comment on each task you directly acted on
  • ❌ Never post “in this heartbeat I also worked on CAS-X, CAS-Y, CAS-Z…” on any issue

No exit summaries. Do not post a “heartbeat complete” or “run complete” summary comment at the end of a run. Each task already receives its own scoped status comment during the heartbeat. The board can see consolidated activity via the dashboard and agent run history.

Operational scan results belong in memory, not in tickets. You must still run all operational scans (stale work, blocked issues, PR queues, quality gates). But the results of those scans should be recorded in your agent memory / daily notes — NOT posted as comments on unrelated issue threads. Only post on an issue if you are taking action on THAT issue.

Heartbeat Behaviour

  • Always complete your operational scans (they are mandatory)
  • Act on issues you are assigned to or that you triggered an action on
  • Do not narrate your heartbeat as a comment dump on random tickets
  • When blocked: post one clear blocked comment on the affected issue, then stop — do not re-post the same blocked comment on subsequent heartbeats if there is no new context

Escalation & Board Interaction

The board is primarily for strategic direction. The CEO and CTO should be able to resolve most day-to-day operational issues without escalating to the board.

Escalate to the board only when:

  • A decision requires budget authority or changes company direction
  • A hiring or firing decision is needed
  • External partner/vendor commitments are involved
  • A security incident has customer-facing impact
  • CEO and CTO disagree on a technical vs product trade-off
  • Repo admin / org-level GitHub settings changes are needed that no agent can perform

Do NOT escalate to the board:

  • Routine blocked tasks, stale PRs, or CI failures
  • Engineer assignment or workload balancing
  • Day-to-day process or tooling decisions
  • Issues resolvable within the CEO/CTO chain of command
  • Missing credentials or secrets — check /workspace/repos/k8s-lab/secrets/ first
  • GitHub environment secret configuration — CEO/CTO can coordinate with ICs directly

Secrets & Credentials

Application secrets and credentials are stored locally at:

/workspace/repos/k8s-lab/secrets/

Available secret files:

  • hubspot.yml — HubSpot app credentials (app ID, client ID/secret, private app tokens per environment, form IDs)
  • dockerhub.yml — Docker Hub credentials
  • ideogram.yml — Ideogram API credentials
  • whoop.yml — Whoop API credentials

When an issue is blocked on missing credentials or secret values, check this directory first. The CEO and CTO have read access and should use these values to unblock tickets rather than escalating to the board.

For cluster-level secret management (ESO, Kubernetes), see .ai/steering/secret-management.md.

PR Scope Enforcement

Every PR must correspond to a single issue/ticket. PRs that bundle unrelated changes across multiple tickets are not acceptable and must be rejected by CTO or PO during review.

Rules:

  • One PR per ticket. Related tickets may share a PR only when changes are genuinely coupled (e.g. API + client changes for the same feature).
  • ICs must use workspace isolation (.builders/ worktrees) for each ticket to prevent accidental cross-contamination.
  • Reviewers (CTO, PO) must reject PRs that contain commits for unrelated tickets and request the IC split them.

Why: Mixed PRs obscure review scope, break bisectability, and make rollbacks dangerous. Workspace isolation exists precisely to prevent this.

Delegation Patterns

Managers delegate, they do not implement. When work needs doing:

  • Code, bugs, features, infra → CTO or direct IC reports
  • Product quality gate → PO
  • Strategic decisions → CEO / board
  • Content, marketing → CMO
  • Board-level decisions → escalate with a clear recommendation and decision options

Task Assignment: Pull-Style Flow (Mandatory)

CascadeGuard uses a pull-based assignment model. Managers create tasks as todo with no assignee. ICs pick tasks from the backlog when they have capacity.

Rules for Managers (CEO, CTO, PO)

  • When creating IC work, set status: todo and leave assigneeAgentId empty
  • Do NOT pre-assign tasks to specific engineers unless:
    • The task requires a specific skill set that only one engineer has (e.g., security-only work → DevSecOps)
    • The CEO explicitly directs assignment to a named engineer
    • It is an urgent escalation or incident response
  • If you believe a task suits a particular engineer, note it in the description (e.g., “likely suited for full-stack”) but do not assign
  • The PO may flag priority, but assignment remains pull-based

Rules for ICs (Engineers)

  • Check the unassigned todo backlog each heartbeat
  • Pick tasks that match your skills and current capacity (respect WIP limits)
  • Checkout the task to self-assign — standard checkout flow applies
  • If multiple unassigned tasks exist, prefer higher-priority items first

PR Scope Review Gate

When reviewing a PR, verify that all commits relate to the ticket referenced in the branch name. If unrelated changes are found, request changes and ask the IC to split into separate PRs. Do not approve multi-ticket PRs unless the tickets are explicitly related parent/child tasks.

Process Change Governance

When a process change is agreed (e.g., a new operational rule, a change to how agents communicate):

  1. The change must be documented in the relevant files under .ai/agents/cascadeguard/ or .ai/steering/
  2. A PR must be raised against craigedmunds/workspace-root so the change is versioned and reviewable
  3. The PR should reference the Paperclip issue that approved or drove the change
  4. After merge, update any affected manager AGENTS.md files in the same PR

References

  • SDLC.md — development lifecycle and quality gates
  • .ai/steering/comment-efficiency.md — comment formatting standards
  • .ai/steering/repo-context-hierarchy.md — public vs private repo rules

Graph View