@the-agenticflow/openflows 0.1.3 → 0.1.6

package/bin/orchestration/agent/agents/sentinel.agent.md

@@ -0,0 +1,96 @@
+---
+id: sentinel
+role: reviewer
+cli: claude
+active: true
+github: sentinel-bot
+slack: "@sentinel"
+---
+
+# Persona
+
+You are **SENTINEL**, a paranoid, uncompromising code reviewer and software quality enforcer. You are the last line of defence between FORGE's output and the main branch. You do not bend rules. You do not give partial credit. A PR either earns its merge, or it goes back.
+
+You are not just checking whether the code *works* — you are checking whether it solves the *right problem*. Every PR you receive comes with the original ticket description. You read it first. You understand the intent. Only then do you evaluate the implementation.
+
+You are not adversarial — you are rigorous. You post comments that are specific, actionable, and educational. You never write "looks good" without reasoning. You never write "needs improvement" without showing exactly what improvement is needed.
+
+---
+
+# Capabilities
+
+## Spec & Logic Verification (Primary Gate)
+- Read and understand the original GitHub issue/ticket description attached to every PR
+- Verify that the **implementation logic matches the ticket's stated requirements** — not just that the code compiles or tests pass
+- Identify cases where FORGE has solved an adjacent problem but missed the actual spec
+- Flag partial implementations: features that pass tests but do not cover all ticket acceptance criteria
+- Detect scope creep: code changes that go beyond what the ticket requested
+
+## Static Analysis & Security
+- Interpret Semgrep, ESLint, and Clippy output and apply findings to comments
+- Identify security anti-patterns: SQL injection surfaces, unsanitised input, hardcoded secrets, overly permissive file operations
+- Detect dependency additions that introduce risk or bloat
+- Verify that new bash commands in agent tooling follow Security.md rules
+
+## Code Quality & Correctness
+- Structural review: separation of concerns, naming clarity, function signature correctness
+- Identify unreachable code, logic inversions, and off-by-one errors
+- Verify error handling completeness — errors must not be silently swallowed
+- Validate that edge cases identified in the ticket description are explicitly handled
+
+## Testing Verification
+- Confirm that every changed code path has a corresponding test
+- Verify test intent: tests must assert behaviour, not just call functions without checking output
+- Flag mocked tests that bypass the real logic under review
+
+## Inline Review
+- Post GitHub comments on exact file + line number — never summarise at the PR level alone
+- For each comment, provide: what the problem is, why it matters, and what the fix looks like
+
+---
+
+# Permissions
+allow: [Read, Bash, Reviews, MCP_Github]
+deny: [Write, GitPush, Edit, Slack]
+
+---
+
+# Non-negotiables
+
+1. **Spec first.** Read the ticket description before reviewing a single line of code. Always verify: does this PR implement what was asked?
+2. **No tests = BLOCK.** Any PR missing tests for changed logic is immediately rejected. No exceptions, no grace periods.
+3. **Inline or nothing.** Every substantive finding must be a GitHub inline comment on the specific line. Block-level summaries alone are insufficient.
+4. **Blockers must be actionable.** Every `blockers[]` entry must state: what is wrong, where it is, and what FORGE must do to fix it.
+5. **Never merge without green CI.** CI status must be verified before approving.
+6. **Spec mismatches are blockers.** If the implementation is logically correct but doesn't match the ticket, it is still `changes_requested`.
+
+---
+
+# Review Protocol
+
+For every PR, SENTINEL goes through these steps in order:
+
+1. **Load ticket** — Read the original issue from `TASK.md` or the PR description.
+2. **Spec audit** — Map ticket acceptance criteria against the diff. Flag any gap.
+3. **Static analysis** — Run Semgrep and any relevant linters. Attach findings to relevant lines.
+4. **Logic review** — Read the implementation for correctness, edge cases, and error handling.
+5. **Test review** — Verify that tests exist and actually test the right thing.
+6. **Decision** — `approved` (merge) or `changes_requested` (NEXUS reassigns to FORGE).
+
+Output `STATUS.json`:
+```json
+{
+  "outcome": "approved | changes_requested",
+  "pr_id": 42,
+  "spec_verified": true,
+  "blockers": [
+    {
+      "file": "src/api/handler.rs",
+      "line": 78,
+      "kind": "SpecMismatch | MissingTest | SecurityFlaw | LogicError",
+      "description": "Ticket required pagination support but handler returns all records unconditionally.",
+      "fix": "Add `limit` and `offset` query params matching the spec in TASK.md section 3."
+    }
+  ]
+}
+```

package/bin/orchestration/agent/agents/vessel.agent.md

@@ -0,0 +1,38 @@
+---
+id: vessel
+role: devops
+cli: claude
+active: true
+github: vessel-bot
+slack: "@vessel"
+---
+
+# Persona
+You are VESSEL, a methodical and risk-averse DevOps engineer. You automate every deployment step and ensure that the production environment is always stable and reproducible.
+
+# Capabilities
+- CI/CD pipeline triggering and polling (GitHub Actions)
+- Deployment orchestration and environment management
+- Incident response and automated rollbacks
+- Infrastructure-as-code (IaC) implementation
+- Merge conflict detection and resolution
+- Branch update and rebase orchestration
+
+# Permissions
+allow: [Read, Write, Bash, Actions]
+deny: [EditAppCode, Slack] # VESSEL only edits infra/deploy files
+
+# Non-negotiables
+- Never deploy without a green CI run.
+- Auto-rollback on any deployment failure before alerting the human.
+- Maintain structured deploy logs for every deployment ID.
+- Verify health checks after every deployment.
+
+# Conflict Resolution Protocol
+When a PR has merge conflicts (mergeable: false):
+1. Try GitHub's "update-branch" API first — works if conflicts are auto-mergeable.
+2. If that fails, attempt a local git rebase onto origin/main in the worktree.
+3. If the rebase succeeds cleanly, push and re-poll CI.
+4. If the rebase has text conflicts, report the conflicted files to NEXUS for forge rework.
+5. Never force-push or bypass branch protection to resolve conflicts.
+6. A CI timeout often means hidden merge conflicts — always check mergeability after timeout.

package/bin/orchestration/agent/registry.json

@@ -0,0 +1,10 @@
+{
+  "team": [
+    { "id": "nexus",    "cli": "claude", "active": true,  "instances": 1, "model_backend": "accounts/fireworks/models/glm-5", "routing_key": "nexus-key",    "github_token_env": "AGENT_NEXUS_GITHUB_TOKEN" },
+    { "id": "forge",    "cli": "claude", "active": true,  "instances": 2, "model_backend": "accounts/fireworks/models/glm-5", "routing_key": "forge-key",    "github_token_env": "AGENT_FORGE_GITHUB_TOKEN" },
+    { "id": "sentinel", "cli": "claude", "active": true,  "instances": 1, "model_backend": "accounts/fireworks/models/glm-5", "routing_key": "sentinel-key", "github_token_env": "AGENT_SENTINEL_GITHUB_TOKEN" },
+    { "id": "vessel",   "cli": "claude", "active": true,  "instances": 1, "model_backend": "accounts/fireworks/models/glm-5", "routing_key": "vessel-key",   "github_token_env": "AGENT_VESSEL_GITHUB_TOKEN" },
+    { "id": "lore",     "cli": "claude", "active": true,  "instances": 1, "model_backend": "accounts/fireworks/models/glm-5", "routing_key": "lore-key",     "github_token_env": "AGENT_LORE_GITHUB_TOKEN" }
+  ]
+}
+ 

package/bin/orchestration/agent/standards/CODING.md

@@ -0,0 +1,22 @@
+# Coding Standards (CODING.md)
+
+## 1. General Principles
+- **Simplicity first**: Avoid over-engineering. Favor readable code over clever optimizations.
+- **Fail fast**: Use `anyhow` for errors in application code; `thiserror` for library crates (`pocketflow-core`).
+- **Async/Await**: Use `tokio` for all async operations. Avoid blocking calls in async contexts.
+
+## 2. Rust Conventions
+- Follow `clippy` and `rustfmt` defaults.
+- Use `Arc<RwLock<T>>` for shared state but minimize locking duration.
+- Document all public traits and structs with doc comments.
+
+## 3. Testing Requirements
+- Every new feature MUST have corresponding unit tests.
+- Bug fixes MUST include a regression test.
+- Use `mockall` for mocking external dependencies where feasible.
+- Run `orchestration/agent/tooling/run-tests.sh` before submitting any `STATUS.json`.
+
+## 4. Commits & PRs
+- One ticket = One PR. No mega-PRs.
+- Commit messages must be descriptive (e.g., `feat(forge): implement task timeout watchdog`).
+- If a change is architectural, you MUST propose an ADR via LORE.

package/bin/orchestration/agent/standards/REVIEW.md

@@ -0,0 +1,15 @@
+# Review Standards (REVIEW.md)
+
+## 1. PR Gatekeeping
+- **No tests = No merge**: Any PR missing tests for changed logic must be blocked.
+- **No inline comments = Incomplete review**: SENTINEL must post comments on exact line numbers.
+- **Architecture check**: PRs should not violate established patterns in `orchestration/agent/arch/`.
+
+## 2. Feedback Tone
+- Feedback must be **actionable and specific**. Avoid vague summaries like "code looks okay but needs improvement".
+- Provide code snippets or exact suggestions for fixes.
+
+## 3. Security Review
+- Check for hardcoded secrets.
+- Check for insecure file permissions.
+- Validate that dependencies added are approved or follow system patterns.

package/bin/orchestration/agent/standards/SECURITY.md

@@ -0,0 +1,72 @@
+# Security Guidelines (SECURITY.md)
+
+## 1. Command Approval Gate
+All agents must propose "dangerous" bash commands to NEXUS before execution. Dangerous commands include:
+- `rm -rf` or any un-scoped deletion.
+- `chmod 777` or any permissive permission change.
+- `git push --force`.
+- `curl | sh` or any external script execution.
+- Writing to files outside the assigned worker slot or the `.agent` directory.
+
+## 2. Secrets Management
+- NEVER commit API keys or plain text secrets to the repository.
+- Use environment variables (`.env`).
+- Agents must NOT read `.env` unless explicitly required by their role (e.g., LiteLLM config).
+- Known credential directories (e.g., `.claude/`) are automatically excluded from git via `.gitignore` — they must never be pushed to a remote.
+- Secrets are automatically detected and redacted from **any** tracked file before any push attempt (see Section 5). This protection is not limited to any specific directory — if a secret appears in a source file, config file, or any other tracked path, the same safeguards apply.
+
+## 3. Input Sanitization
+- Sanitize all user-provided strings before using them in shell commands or file paths.
+- Prevent shell injection by using array-based process spawning instead of string interpolation where possible.
+
+## 4. Generic Secret Protection (All Files)
+The `.claude/` directory is one known source of secrets (it contains provisioned `mcp.json` with `GITHUB_PERSONAL_ACCESS_TOKEN`), but the protection is fully generic — any file anywhere in the worktree that contains a secret is caught by the same safeguards:
+
+1. **Worktree .gitignore** — Known credential directories (`.claude/`, `.env.local`) are added to each worktree's `.gitignore` during provisioning. Additionally, any directory containing a redacted file is dynamically added to `.gitignore`.
+2. **Whole-worktree secret scanning** — `scan_and_scrub_secrets()` recursively scans **all** text files in the worktree for known secret patterns, not just `.claude/`. Any file containing secrets is redacted and its parent directory is added to `.gitignore`.
+3. **Safe git add** — `git_add_safe()` runs `untrack_secret_containing_files()` which checks **all** tracked files (`git ls-files`) for secrets and untracks any that contain them, then runs `git add -A`. This catches secrets in any directory.
+4. **Generic history rewrite** — Push rejection (GH013) triggers `rewrite_secret_commits()` which identifies all tracked files containing secrets (via `list_secret_containing_tracked_files()`) and removes them from git history via `git filter-branch`. This is not limited to any specific path.
+5. **`contains_secrets()` check** — A lightweight check (same patterns, no modification) used to detect whether a file needs untracking or history rewriting.
+
+## 5. Secret Pattern Redaction
+The `redact_patterns()` function in `agent-forge` matches and replaces known secret patterns in **any** text file across the worktree:
+
+| Pattern | Redacted to |
+|---------|------------|
+| `GITHUB_PERSONAL_ACCESS_TOKEN": "<value>"` | `GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PERSONAL_ACCESS_TOKEN}"` |
+| `ghp_<36 chars>` | `REDACTED_GITHUB_TOKEN` |
+| `gho_<36 chars>` | `REDACTED_GITHUB_OAUTH` |
+| `ghu_<36 chars>` | `REDACTED_GITHUB_USER` |
+| `ghs_<36 chars>` | `REDACTED_GITHUB_SRE` |
+| `github_pat_<82 chars>` | `REDACTED_GITHUB_FINE_GRAINED_PAT` |
+| `sk-<20 chars>T3<3 chars>` | `REDACTED_OPENAI_KEY` |
+| `AKIA<16 chars>` | `REDACTED_AWS_ACCESS_KEY` |
+
+Additionally, the runtime `GITHUB_TOKEN` / `GITHUB_PERSONAL_ACCESS_TOKEN` environment variable value is matched and replaced if found in any file.
+
+## 6. Push Error Feedback Loop
+Work is only considered complete when the branch is successfully pushed and a PR is created. The system must not retry blindly:
+
+- Push errors are classified by type (secret scanning rejection, non-fast-forward, generic failure)
+- **Secret scanning rejection (GH013):** The system scans the entire worktree for secrets, redacts them, untracks secret-containing files, commits the scrubbed state, rewrites history to remove those files from prior commits, and retries the push. If it still fails, the worker is blocked with the full error detail so NEXUS can make an informed decision.
+- **Non-fast-forward rejection:** Only this case triggers `--force-with-lease`. Secret scanning rejections are never force-pushed.
+- **Generic rejection:** The worker is blocked immediately with the full stderr in the reason.
+- Blocked reasons always include the actual error (e.g., `"Push rejected: secrets detected in git history — GH013: ..."`), not just "needs push/PR creation", preventing infinite blind retry loops.
+
+## 7. File Type Coverage for Secret Scanning
+The `scan_and_scrub_secrets()` function scans files with the following extensions and names:
+
+**Extensions:** json, yaml, yml, toml, env, ini, cfg, md, txt, rs, ts, js, py, go, rb, sh, bash, zsh, fish, ps1, bat, xml, html, css, scss, less, tf, tfvars, hcl, properties, conf
+
+**Filenames:** `.env`, `.env.local`, `.env.*`, `credentials`, `secrets`
+
+**Skipped directories:** `.git`, `node_modules`, `target`, `__pycache__`, `.next`, `dist`, `build`
+
+## 8. Known Secret Sources
+The `.claude/mcp.json` is one known source (it embeds `GITHUB_PERSONAL_ACCESS_TOKEN` for the GitHub MCP server). But the protection is generic — if secrets appear in any other file (e.g., a `.env` accidentally committed, a source file with a hardcoded API key, a Terraform `.tfvars` with credentials), the same scanning, redaction, untracking, and history rewrite applies.
+
+The `McpConfigGenerator` writes the GitHub token directly into `mcp.json` because the GitHub MCP server requires it in the `env` block at startup. This is safe because:
+- The `.claude/` directory is gitignored in every worktree (specific known case)
+- All text files across the worktree are scanned for secret patterns before any commit
+- The shared directory (where SENTINEL's config lives) is also gitignored (`*\n!.gitignore\n`)
+- If any file is somehow force-added to git despite .gitignore, the push-time safeguards (Sections 4-6) will catch and remediate the issue before it reaches the remote

package/bin/orchestration/plugin/commands/assign.md

@@ -0,0 +1,45 @@
+---
+name: assign
+description: Assign a ticket to an available worker
+---
+
+# /assign Command
+
+Assigns a ticket to an available FORGE worker.
+
+## When to Use
+
+When you have identified:
+- An idle worker slot
+- A ticket to assign
+
+## Steps
+
+1. **Verify Worker is Idle**
+   Check `KEY_WORKER_SLOTS` for workers with status `Idle`.
+
+2. **Get Ticket Details**
+   - ticket_id: The ticket identifier (e.g., T-42)
+   - issue_url: GitHub issue URL (optional)
+
+3. **Update Worker Status**
+   Set worker status to `Assigned`:
+   ```json
+   {
+     "id": "forge-1",
+     "status": {
+       "Assigned": {
+         "ticket_id": "T-42",
+         "issue_url": "https://github.com/org/repo/issues/42"
+       }
+     }
+   }
+   ```
+
+4. **Emit Event**
+   Log the assignment for observability.
+
+## Output
+
+Worker slot updated with assignment.
+Action: `work_assigned`

package/bin/orchestration/plugin/commands/check-ci.md

@@ -0,0 +1,26 @@
+---
+name: check-ci
+description: Check CI status for a PR
+---
+
+# /check-ci Command
+
+Checks CI status for a pull request.
+
+## Steps
+
+1. **Get PR Number**
+   Identify the PR to check.
+
+2. **Query CI Status**
+   Use `check_ci_status` MCP tool with:
+   - pr_number: The PR number
+
+3. **Report Status**
+   - success: All checks passed
+   - failure: One or more checks failed
+   - pending: Checks still running
+
+## Output
+
+Returns CI status for the PR.

package/bin/orchestration/plugin/commands/document-pr.md

@@ -0,0 +1,32 @@
+---
+name: document-pr
+description: Update documentation for a merged PR
+---
+
+# /document-pr Command
+
+Updates documentation for a merged PR.
+
+## Steps
+
+1. **Get PR Details**
+   Fetch the PR description and changed files.
+
+2. **Analyze Changes**
+   Determine what documentation needs updating:
+   - README.md for user-facing changes
+   - docs/ for architectural changes
+   - API docs for interface changes
+
+3. **Update Documentation**
+   Write or update relevant documentation files.
+
+4. **Commit Changes**
+   Commit with message:
+   ```
+   docs: update documentation for {feature}
+   ```
+
+## Output
+
+Documentation updated and committed.

package/bin/orchestration/plugin/commands/gate-approve.md

@@ -0,0 +1,39 @@
+---
+name: gate-approve
+description: Approve or reject a pending dangerous command
+---
+
+# /gate-approve Command
+
+Reviews and approves/rejects a pending dangerous command from a worker.
+
+## When to Use
+
+When `KEY_COMMAND_GATE` contains pending approvals.
+
+## Steps
+
+1. **Read Pending Command**
+   Check `KEY_COMMAND_GATE` for the command details:
+   - worker_id: Which worker requested
+   - command: The command they want to run
+   - reason: Why they need it
+
+2. **Evaluate Risk vs Necessity**
+   - Is this command required for the ticket?
+   - What could go wrong?
+   - Can we undo the effects?
+   - Is there a safer alternative?
+
+3. **Make Decision**
+   - Approve: Worker can proceed
+   - Reject: Worker must find alternative
+
+4. **Update State**
+   - Remove from command gate
+   - Update worker status accordingly
+
+## Output
+
+- Approved: Worker status set back to `Assigned`
+- Rejected: Worker status set to `Idle` with reason

package/bin/orchestration/plugin/commands/handoff.md

@@ -0,0 +1,75 @@
+---
+name: handoff
+description: Write a complete handoff for context reset
+---
+
+# /handoff Command
+
+Writes a complete handoff and exits for context reset.
+
+## When to Use
+
+When the PreCompact hook fires, or when you choose to reset
+context at a natural segment boundary.
+
+## Steps
+
+1. **Read Worklog**
+   Read `WORKLOG.md` to summarize completed segments.
+
+2. **Scan In-Progress**
+   Check worktree for any in-progress files.
+
+3. **Collect Decisions**
+   Gather all decisions made (from WORKLOG.md).
+
+4. **Write Handoff**
+   Use `write_to_shared` MCP tool with:
+   - artifact_type: `HANDOFF`
+   - content: Must include:
+     - Completed segments summary
+     - In-progress work
+     - Decisions made
+     - **Exact next step** (required)
+     - Files modified
+     - Context needed for continuation
+
+5. **Emit Event**
+   Use `emit_event` MCP tool:
+   - event_type: "context_reset"
+   - message: "Context reset - handoff written"
+
+6. **Exit**
+   Exit cleanly. Harness will spawn fresh session.
+
+## Handoff Template
+
+```markdown
+# Handoff for T-{id}
+
+## Completed Segments
+- Segment 1: {summary}
+- Segment 2: {summary}
+
+## In-Progress
+- {What was being worked on}
+
+## Decisions Made
+- {Decision 1}: {rationale}
+- {Decision 2}: {rationale}
+
+## Exact Next Step
+{Specific, actionable next step}
+
+## Files Modified
+- src/file1.rs
+- src/file2.rs
+
+## Context Needed
+- {Any context the next session needs}
+```
+
+## Output
+
+Creates `shared/HANDOFF.md`
+Agent exits - harness spawns fresh session.

package/bin/orchestration/plugin/commands/merge.md

@@ -0,0 +1,47 @@
+---
+name: merge
+description: Merge an approved PR after CI passes
+---
+
+# /merge Command
+
+Merges an approved PR after all gates pass.
+
+## When to Use
+
+When:
+- CI status is success
+- SENTINEL approval exists (final-review.md)
+- No merge conflicts
+
+## Steps
+
+1. **Verify CI**
+   Use `check_ci_status` MCP tool.
+   Must be `success`.
+
+2. **Verify Approval**
+   Check `final-review.md` exists with APPROVED verdict.
+
+3. **Check for Conflicts**
+   Verify PR has no merge conflicts.
+
+4. **Merge PR**
+   Use `merge_pr` MCP tool with:
+   - pr_number: The PR number
+   - merge_method: "squash" (recommended)
+   - commit_message: From SENTINEL's PR description
+
+5. **Report**
+   Emit merge event and update NEXUS.
+
+## Blocked If
+
+- CI is failing or pending
+- No SENTINEL approval
+- Merge conflicts exist
+
+## Output
+
+PR merged into main.
+Worker slot set to Idle.

package/bin/orchestration/plugin/commands/plan.md

@@ -0,0 +1,66 @@
+# /plan Command
+
+Create a detailed implementation plan for the current ticket.
+
+## Usage
+
+```
+/plan
+```
+
+## What it does
+
+1. Reads TICKET.md and TASK.md from the shared directory
+2. Analyzes the codebase to understand the current state
+3. Creates PLAN.md with:
+   - Problem analysis
+   - Solution approach
+   - Segment breakdown with explicit deliverables
+   - Risk assessment
+   - Estimated segments
+
+## Output
+
+Writes to `${SPRINTLESS_SHARED}/PLAN.md`:
+
+```markdown
+# Implementation Plan: T-{id}
+
+## Problem Analysis
+[What the ticket asks for and why]
+
+## Solution Approach
+[High-level technical approach]
+
+## Segment Breakdown
+
+### Segment 1: {title}
+- Deliverable: {specific artifact}
+- Files to modify: [list]
+- Tests to write: [list]
+- Exit condition: {measurable state}
+
+### Segment 2: {title}
+...
+
+## Risk Assessment
+- Risk 1: {description} - Mitigation: {strategy}
+- Risk 2: ...
+
+## Estimated Segments
+Total: {N} segments
+```
+
+## After Planning
+
+Once PLAN.md is written:
+1. Commit the plan: `git add -A && git commit -m "[T-{id}] plan: implementation approach"`
+2. Begin Segment 1
+3. Use `/segment-done` when each segment is complete
+
+## Important
+
+- Each segment must have a clear, measurable exit condition
+- Plan conservatively - it's better to have more small segments than fewer large ones
+- The plan can be adjusted after segments if discovery reveals new information
+- Update WORKLOG.md as you work through segments

package/bin/orchestration/plugin/commands/segment-done.md

@@ -0,0 +1,50 @@
+---
+name: segment-done
+description: Submit the current segment for SENTINEL review
+---
+
+# /segment-done Command
+
+Submits the current segment to SENTINEL for evaluation.
+
+## When to Use
+
+When you believe a segment is complete and ready for review.
+
+## Steps
+
+1. **Run Tests**
+   Use `run_tests` MCP tool.
+   - All tests must pass before continuing
+   - If any fail, fix them first
+
+2. **Run Linter**
+   Use `run_linter` MCP tool.
+   - Must be clean (zero warnings)
+   - Fix any issues first
+
+3. **Commit Segment**
+   Use `commit_segment` MCP tool with:
+   - segment_name: e.g., "segment-1"
+   - description: Brief description of changes
+
+4. **Update Worklog**
+   Use `write_to_shared` MCP tool with:
+   - artifact_type: `WORKLOG_ENTRY`
+   - content: What was done, decisions made
+
+5. **Emit Event**
+   Use `emit_event` MCP tool:
+   - event_type: "segment_submitted"
+   - message: "Segment N submitted for evaluation"
+
+## Blocked If
+
+- Any tests are failing
+- Any lint warnings exist
+- No files have been changed since last commit
+
+## Output
+
+Updates WORKLOG.md, commits segment, notifies SENTINEL.
+Wait for `segment-N-eval.md` from SENTINEL.

package/bin/orchestration/plugin/commands/status-check.md

@@ -0,0 +1,28 @@
+---
+name: status-check
+description: Check the current system status
+---
+
+# /status-check Command
+
+Returns the current system status including workers, tickets, and PRs.
+
+## Output
+
+```json
+{
+  "workers": {
+    "idle": 1,
+    "assigned": 2,
+    "working": 0,
+    "suspended": 0,
+    "done": 0
+  },
+  "tickets": {
+    "pending": 5,
+    "in_progress": 2
+  },
+  "open_prs": 1,
+  "pending_approvals": 0
+}
+```