EZAlgo Command Center — Agent Instructions

The Eleven Commandments — Read These First

The full detail for each rule lives below this index. If you only read one section, read this one.

1. Where things run — Windows hosts MT5/Supabase/LiveTrading. Hyper-V Ubuntu hosts everything else. → HARD RUNTIME RULE
2. GitNexus is mandatory — Always start with GitNexus, never with grep/read/bash. ~100 tokens vs ~3000. → GitNexus — Mandatory
3. Plan → discuss → approve → plan → move forward — Never talk-then-implement, even with build mode on. → Working with Andres
4. Search for an available skill FIRST — CE skills are the baseline toolkit. → The Four Non-Negotiables
5. Use the MCP servers — context7, sequential-thinking, etc. They are first-class tools. → The Four Non-Negotiables
6. Look up online documentation BEFORE implementing — We don’t guess at APIs. → The Four Non-Negotiables
7. Publish critical online docs INTO the project — Capture them in the knowledge base or Docmost. → The Four Non-Negotiables
8. The Pet Peeve Rule — Never do the same wrong thing twice. Never loop three times without using the tools. → The Pet Peeve Rule
9. PUBLISH EVERY PLAN to the knowledge base — If it only exists in chat, it doesn’t exist. → Jekyll Knowledge Base
10. NEVER commit, push, or merge without explicit human confirmation — “yes commit” or “push it” required. → Critical Rules
11. Cascade delete: strategies → setups → parameters → badges → signals — No orphans, ever. → Critical Rules

Section index:

• HARD RUNTIME RULE — Where Things Run
• GitNexus — Mandatory at Workflow Checkpoints
• Behavioral Guidelines
• Critical Rules
• Complexity Discipline
• Solution Bias Guardrail
• Rust Preference
• AI Tooling Extensions
• Jekyll Knowledge Base — PUBLISH EVERY PLAN
• Working with Andres — The Baseline Workflow
• Read Before You Act
• GitNexus — Code Intelligence

HARD RUNTIME RULE — Where Things Run

The runtime is split across two hosts. This is a fact, not a suggestion — agents who get this wrong waste hours.

Implications for agents:

• For Docker, Compose, deployment, GitLab Runner, runtime logs, service status, ports, CI/CD: work in Hyper-V Ubuntu directly.
• For MT5 connector, Windows-native Supabase, or anything that needs MT5 DLL access: work in Windows (PowerShell).
• If the agent is about to run a Windows command for runtime/deploy work, it must stop and explain why Hyper-V Ubuntu is not being used.

Never treat application deployment as:

• Windows OpenSSH for app deployment (it’s for the MT5/Supabase side only)
• Windows service management for app services
• SSH into host.docker.internal for app services
• Windows Docker context for app services
• DEPLOY_SSH_KNOWN_HOSTS for local Hyper-V Ubuntu deploy

EZAlgo is a futures trading platform with a Rust-first, zero-copy data architecture. Market data flows from MT5 (Windows) through a Rust range bar builder (Hyper-V Ubuntu), into Arrow/Parquet for computation, and out to a SciChart WebGL chart via Arrow IPC. Python services run in Docker on Hyper-V Ubuntu. The live trading service runs natively on Windows (needs MT5 DLL access).

GitNexus — Mandatory at Workflow Checkpoints

GitNexus is the primary research engine. It is mandatory — every agent MUST use it before falling back to raw file search. It indexes 44758 symbols, 55598 relationships, and 300 execution flows. GitNexus queries return structured, ranked results that save thousands of tokens and minutes of file-hunting. Graphify is secondary — use it only when GitNexus doesn’t cover the need.

Always start with GitNexus. Never start with grep/read/bash. Better research, more targeted research, for less money — GitNexus is cheaper than raw file search by a wide margin (~100 tokens vs ~3000 tokens for equivalent coverage). Raw file search is the fallback, not the default.

Every agent must consult GitNexus at these checkpoints:

1. Before researching/understanding code — Use GitNexus query and context tools FIRST. Only fall back to grep/read when GitNexus has no results.
2. Before editing any file — Run gitnexus_impact({target: "symbolName", direction: "upstream"}) to get blast radius. Report risk to the user.
3. After implementing a feature — Run gitnexus_detect_changes() to verify your changes only affect expected symbols.
4. Before an audit or review — Use GitNexus query for specific flows. Use GitNexus context for symbol-level verification.
5. After a commit — GitNexus reindexes when gitnexus analyze runs (typically on demand or CI).
6. Before any plan — Search GitNexus for existing implementations to avoid duplicating work.

GitNexus-first research hierarchy:

Why GitNexus first: A single gitnexus_query call returns the same information that would require 5-15 grep + read cycles, but ranked by relevance and grouped by execution flow. It costs ~100 tokens vs ~3000 tokens for manual search. Use it.

Index Updates Must Never Block the Workflow

GitNexus and Graphify index updates are background tasks. NEVER run them synchronously in the middle of a workflow. The agent must keep working with the current index state and let updates happen asynchronously.

Rules:

• NEVER wait for gitnexus analyze to finish before continuing work. Fire it in the background and move on.
• NEVER wait for gitnexus analyze or Graphify rebuild to complete before committing. The index will catch up.
• NEVER block the user’s workflow to refresh an index. Use the stale index data — it’s almost always good enough.
• If a commit hook triggers a Graphify rebuild, it runs automatically. Do not stop to check on it or wait for it.
• If the GitNexus index is stale, note it once and continue. Run gitnexus analyze & (background) if a refresh is needed, then proceed with the current data.
• The only exception: if a gitnexus_impact call explicitly warns “index is too stale for reliable results,” mention it to the user and ask whether to wait or proceed. But still do not block automatically.

Pattern for background updates:

gitnexus analyze &   # fire and forget — index refreshes in background, workflow continues

GitNexus indices and Graphify outputs are first-class generated project artifacts, not junk. If they change because of commit hooks or background updates, they will be picked up in the next session or query.

Behavioral Guidelines

These bias toward caution over speed. For trivial tasks, use judgment.

1. Think Before Coding

Don’t assume. Don’t hide confusion. Surface tradeoffs.

• State your assumptions explicitly. If uncertain, ask.
• If multiple interpretations exist, present them — don’t pick silently.
• If a simpler approach exists, say so. Push back when warranted.
• If something is unclear, stop. Name what’s confusing. Ask.
• Read the docs first. If a tool/platform has official docs (Docker, etc.), find and read them BEFORE trying anything. Don’t guess.

2. Simplicity First

Minimum code that solves the problem. Nothing speculative.

• No features beyond what was asked.
• No abstractions for single-use code.
• No “flexibility” or “configurability” that wasn’t requested.
• No error handling for impossible scenarios.
• If you write 200 lines and it could be 50, rewrite it.
• Ask yourself: “Would a senior engineer say this is overcomplicated?” If yes, simplify.

3. Surgical Changes

Touch only what you must. Clean up only your own mess.

• Don’t “improve” adjacent code, comments, or formatting.
• Don’t refactor things that aren’t broken.
• Match existing style, even if you’d do it differently.
• If you notice unrelated dead code, mention it — don’t delete it.
• Remove imports/variables/functions that YOUR changes made unused.
• Don’t remove pre-existing dead code unless asked.
• Every changed line should trace directly to the user’s request.

4. Goal-Driven Execution

Define success criteria. Loop until verified.

• “Add validation” → “Write tests for invalid inputs, then make them pass”
• “Fix the bug” → “Write a test that reproduces it, then make it pass”
• “Refactor X” → “Ensure tests pass before and after”
• For multi-step tasks, state a brief plan with verification at each step.
• Strong success criteria let you loop independently. Weak criteria require constant clarification.

5. Listen First

When the user says something is wrong, stop and listen. Don’t reply “it looks correct” without re-verifying.

• If the user corrects your approach, adopt it immediately. Don’t keep pushing the old approach.
• If the user says you’re going in circles, you are. Stop and ask for direction.
• Don’t hack around problems (DB edits, wrong SSH users, workarounds). Fix the root cause.

6. No Silent Scope Changes

When implementation hits friction, do not quietly reduce scope.

• Do not remove a failed config entry, dependency, service, or workflow step unless the user explicitly approves that removal.
• Do not describe only what the omission did not affect. Report what changed, what was omitted, and what practical behavior differs.
• If the fix is discoverable, do the research and attempt the fix. If the fix is uncertain or risky, stop and ask.

These guidelines are working if: fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.

Critical Rules

1. Badges tag with parameter_id only. Never strategy_id or setup_id.
2. Parameters are strategy-level. One parameter_id per indicator name per strategy. All setups within a strategy share the same indicator parameters. Never compute the same indicator twice for different setups.
3. Cascade delete: strategies → setups → parameters → badges → signals. No orphans.
4. Recalculation engine uses direct psycopg2. Never REST API calls between Python services.
5. Badges live in Arrow/Parquet memory. They are NOT written to PostgreSQL. Badge data flows as structured NumPy arrays → Arrow IPC columns → browser TypedArrays.
6. No backwards compat. Build new, delete old. No fallback paths — if the primary path fails, surface the error, don’t silently degrade to a legacy path. No “combined” or “legacy” modes that paper over schema mismatches.
7. All Python services run as Docker Compose containers on Hyper-V Ubuntu. Never run files manually (except live trading MT5 connector — native Windows).
8. Arrow IPC is the ONLY wire format for high-volume data (bars, badges, signals, trades). JSON is never used for compute results.
9. connectorx is the ONLY runtime path for loading bars from PostgreSQL. No row-by-row psycopg2 reads for bar data.
10. Never run npx supabase start or docker compose down without asking.
11. Nautilus Trader architecture graph is available at graphify-out/nautilus_trader/graph.json. Read .agents/reference/nautilus-architecture.md for key patterns (supervisor/worker separation, state machines, event-driven coordination). Query GitNexus for specific comparisons first, fall back to Graphify if needed.

12. NEVER commit, push, or merge without explicit human confirmation. This means: git commit, git push, git merge, gh pr create, gh pr merge — ALL require the user to say “yes commit” or “push it” first. No exceptions.

13. No phase implementation without explicit instruction. Plan approval ≠ execution authorization. After completing a phase, STOP. Present verification results. Wait for the user to say “proceed to Phase N” before starting the next phase. Do not auto-continue through phases.
14. No git push without being asked. Even if a commit is appropriate, do not push unless the user explicitly says “push” or “push it.” Commit only when asked. Push only when asked.
15. Verify before declaring done. After implementing a phase, run the verification checks specified in the plan. Present the results. Do not skip verification and do not assume success.
16. STOP after every phase. Present what was done and verification results. Then shut up and wait. Do not auto-continue. Do not assume “continue” from an earlier instruction still applies after a commit/push. The only trigger for starting the next phase is the user explicitly saying “proceed to Phase N” or equivalent. If in doubt, ask. Making code changes and presenting them for review is fine. Auto-pushing is not.

Complexity Discipline

• Simple problem: no new system
• Every new layer guilty until proven needed
• Prefer closest existing primitive over new abstraction
• If framework/runtime already does it, use direct
• New orchestration, persistence, indirection need explicit proof
• Solve current behavior first, not future maybe
• Optimize for fewer moving parts, files, failure modes
• If solution adds more concepts than problem, stop
• Before big proposal, show 2-3 line version and why not enough
• Default instinct: remove, simplify, inline, reuse. Not invent
• This simplification bias never authorizes omitting requested scope. If simplifying means dropping a requested component or workflow step, ask the human first.

Solution Bias Guardrail

• Do not let specialized tool/framework/prior architecture drive solution by default
• Choose tools from problem + existing codebase, not model specialization
• Specialized systems must beat simplest working in-repo approach
• Reuse existing project primitives first. New infra needs concrete need
• Compare proposal against simplest in-repo mechanism. Explain why not enough
• If specialization pushes complexity, stop and reset from first principles

Rust Preference

• Prefer Rust-based compiled code over Python wherever performance matters
• Prefer Rust-based libraries (polars, connectorx, orjson) over pure-Python alternatives
• When adding new high-performance code, consider Rust PyO3 before Numba JIT
• Follow the ezalgo_bars crate pattern for new Rust modules

AI Tooling Extensions

GitNexus (Code Intelligence) — Primary Research Engine

• What: Code knowledge graph with 44758 symbols, 55598 relationships, 300 execution flows for this repo. MCP server serves all indexed repos via stdio.
• MCP tools: query, context, impact, detect_changes, rename, cypher, list_repos, route_map, tool_map, shape_check, api_impact, group_list, group_sync
• MCP resources: gitnexus://repo/ezalgocommandcenter/context, clusters, processes, process/{name}, schema
• Hooks: Claude Code PreToolUse intercepts Grep/Glob/Bash and augments with graph context automatically. PostToolUse detects stale index after git mutations.
• Status: gitnexus status — check index freshness. Run gitnexus analyze if stale.
• Web UI: gitnexus serve --port 25000 — browse graph at http://localhost:25000

Usage rules are defined in the GitNexus — Mandatory at Workflow Checkpoints section above. GitNexus is the FIRST tool for understanding code, assessing impact, and planning changes.

Skill files for detailed workflows: | Task | Skill | |——|——-| | Understand architecture | gitnexus-exploring | | Blast radius / impact | gitnexus-impact-analysis | | Trace bugs | gitnexus-debugging | | Rename / refactor | gitnexus-refactoring | | CLI commands | gitnexus-cli | | Full reference | gitnexus-guide |

Docmost (Project Wiki + Strategic Docs) — Central Knowledge Hub

• What: Cloud wiki at https://myworkspace-474252.docmost.com. Replaces all scattered .md docs in the repo — plans, requirements, architecture decisions, setup guides, action plans all live here. Connected via MCP for AI agents to search, read, create, and update pages directly.
• MCP tools: search_pages, get_page, create_page, update_page, list_pages, list_child_pages, duplicate_page, copy_page_to_space, move_page, move_page_to_space, get_space, list_spaces, create_space, update_space, get_comments, create_comment, update_comment, search_attachments, list_workspace_members, get_current_user
• Auth: API key passed via Bearer token. Wired into all 3 harnesses (Claude Code, OpenCode, Codex).
• Permissions: Respects Docmost workspace permissions. Read access for existing docs, write access where granted.
• Use when: finding project documentation, creating action plans, reading requirements, writing architecture docs — basically anything that was previously in .md files scattered across the repo. Search Docmost EARLY: before planning, before implementing, when onboarding to any feature. This is the source of truth for non-code knowledge.

Graphify (Knowledge Graph) — Secondary Reference

• What: Local knowledge graph indexed from this codebase. 5394+ nodes, 8565+ relationships. Superseded by GitNexus for most queries — use only when GitNexus doesn’t cover the need.
• Output: graphify-out/graph.json (queryable JSON), graphify-out/GRAPH_REPORT.md (audit report), graphify-out/graph.html (interactive visualization).
• Auto-update: Git hooks auto-rebuild AST on commit/checkout. For doc/paper changes, run /graphify . --update.
• Config: .graphifyignore controls what gets indexed.
• No MCP server needed. The graph is a static JSON file. Any AI tool can read it directly.
• Never block on rebuilds. Graphify updates run in the background via git hooks. Do not stop work to wait for them.

Usage rules are defined in the GitNexus — Mandatory at Workflow Checkpoints section above.

Key commands:

• .\scripts\graphify.ps1 . — build/rebuild the full graph from Codex/PowerShell
• .\scripts\graphify.ps1 . --update — incremental re-extract only changed files from Codex/PowerShell
• .\scripts\graphify.ps1 . --cluster-only — rerun clustering without re-extraction from Codex/PowerShell
• .\scripts\graphify.ps1 query "question" — BFS traversal for broad context
• .\scripts\graphify.ps1 path "A" "B" — shortest path between two concepts
• .\scripts\graphify.ps1 explain "X" — plain-language explanation of a node
• .\scripts\graphify.ps1 hook status — verify auto-rebuild hooks are active
• Slash-command assistants can use the same commands as /graphify ....

Cavemem (Persistent Memory + MCP)

• What: Cross-agent persistent memory. Hooks capture observations at session boundaries, compress with caveman grammar (~75% fewer prose tokens, code and paths preserved byte-for-byte), and write to local SQLite. All harnesses share the same memory store.
• MCP server: cavemem mcp — exposes search, timeline, get_observations, list_sessions. Progressive disclosure: search/timeline return compact results; get_observations fetches full bodies.
• Web viewer: cavemem viewer — opens read-only UI at http://localhost:37777 for browsing sessions in human-readable form.
• Data: ~/.cavemem/data.db (SQLite). Compression: full. Hybrid search: SQLite FTS5 + local vector index (Xenova/all-MiniLM-L6-v2).
• Worker: Auto-spawns on first hook (no daemon to manage). Self-exits when idle. cavemem status to verify.
• Privacy: <private>...</private> stripped at write boundary. Path globs exclude whole directories.
• Use when: recalling decisions, patterns, or context from previous sessions. Query it BEFORE re-reading docs.

Caveman (Token Compression)

• What: Claude Code plugin, OpenCode native plugin, and Codex skill that makes agent talk like caveman — cuts ~75% of output tokens, keeps full technical accuracy. Brain still big, mouth small.
• Installed on all harnesses: Claude Code (plugin + hooks + SessionStart auto-activation), OpenCode (native plugin in ~/.config/opencode/plugins/caveman/), Codex (skills in .agents/skills/caveman/).
• Compression: full — drop articles, use fragments, keep substance. One level below ultra. Switch with /caveman lite|full|ultra|wenyan.
• Triggers: /caveman activates. “normal mode” deactivates. Claude Code auto-activates every session via hooks + ~/.claude/.caveman-active flag. OpenCode activates from session start via AGENTS.md bootstrap.
• Commands: /caveman-commit for conventional commits, /caveman-review for one-line PR comments, /caveman-stats for token savings, /caveman-compress to rewrite memory files.
• Statusline: Claude Code shows [CAVEMAN] ⛏ <saved> in status bar, updating after each caveman-stats run.
• Compounds with cavemem: caveman compresses what agent says, cavemem compresses what agent remembers — token savings stack.

Service Management (Hyper-V Ubuntu)

All commands run inside Hyper-V Ubuntu. SSH in or use your terminal multiplexer of choice from there.

Check CaveMem is running:

export PATH="$HOME/.local/bin:$PATH" && cavemem status

If CaveMem is not working:

export PATH="$HOME/.local/bin:$PATH" && cavemem start     # auto-starts worker on first hook anyway
cavemem viewer                                            # opens viewer at http://localhost:37777

CaveMem auto-starts the worker on first hook hit (hooks write synchronously, worker spawns in background). No systemd service needed. Worker self-exits when idle.

Jekyll Knowledge Base — PUBLISH EVERY PLAN

Every plan, action item, brainstorm, or architectural decision MUST be published to the knowledge base. No exceptions. If you create a plan and it only exists in chat, it doesn’t exist.

Write a plain .md file to the correct .hermes/plans/ subdirectory. The watcher auto-publishes it to https://knowledge.ezalgotrader.com — no frontmatter needed, no manual steps.

Filename: YYYY-MM-DD_descriptive-title.md (e.g. 2026-06-02_rust-range-bar-builder.md)

Tags are critical — they are how we find related content across categories. Tags are auto-derived from filename keywords (hyphens and underscores become tag boundaries). Use descriptive, topic-focused filenames to get good tags.

Tag vocabulary — use these when applicable:

• Core platform: trading, signals, backtesting, strategy, data-pipeline, indicators
• Frontend: chart, frontend, badge
• Backend: backend, rust, infra, observability
• Concerns: architecture, refactor, security, performance, testing

After writing: Verify it appears at https://knowledge.ezalgotrader.com

⚠ If you lost context and don’t understand these categories, tags, or the publishing workflow — STOP. Do not guess. Do not skip publishing. Read the full reference at .hermes/plans/documentation/2026-06-02_knowledge-base-setup.md before proceeding.

Working with Andres — The Baseline Workflow

The default interaction pattern is plan → discuss → approve → plan → move forward. Never talk-then-implement. Not even for a test. Not even when build mode is on. Build mode is a permission system, not a workflow override — the workflow baseline holds regardless.

The ONLY exception: when Andres explicitly says “just do it” / “skip the plan” / “go ahead” — confirm the scope in one sentence, then execute. No further confirmation loops. But this is opt-in, not default. When in doubt, plan.

The Four Non-Negotiables

1. Search for an available skill FIRST.

This is non-negotiable. When Andres asks for research, implementation, or any other work, the very first action is to check installed skills. The compound-engineering (CE) skills are the baseline toolkit — use them whenever they apply. When work is specific to a language or framework, search for that domain’s skill. Skills dramatically improve output quality and reduce time-to-solution.

The friction this rule prevents: agent tries, agent gets it wrong, Andres says “will you search the docs,” agent says “oh yeah, here it is.” That is wasted hours. The answer is already in the installed skills. Use them.

2. Use the MCP servers.

Multiple MCP servers are configured for this project. Examples include context7 (for up-to-date library/framework documentation lookup) and sequential-thinking (for structured multi-step reasoning). Treat MCP servers as first-class tools — check what’s available, use what’s relevant. They are not optional.

3. Look up online documentation BEFORE implementing.

Especially for code-related work — bug fixes, implementation, framework usage, API calls. Official docs are the source of truth. We do not guess at API surfaces, we do not pattern-match from training data, we do not skip the docs because “it probably works the way I remember.”

4. Publish critical online documentation INTO the project.

When we look up online documentation and find material that future work will need, capture it as a project doc and make it accessible to all AI agents. The MD knowledge base (Jekyll section above) and Docmost are the destinations. Reference materials do not survive across chat sessions, but project docs persist across sessions and harness switches. This is why we scrape and publish docs to the knowledge base — to make the answer always available.

CE Skills (Baseline Toolkit)

Plan first: ce-plan, ce-brainstorm, ce-ideate, ce-strategy Build: ce-work, ce-work-beta, ce-worktree Debug: ce-debug Test: ce-test-browser, ce-test-xcode Review: ce-code-review, ce-doc-review, ce-agent-native-audit Commit/PR: ce-commit, ce-commit-push-pr, ce-resolve-pr-feedback Memory: ce-compound, ce-compound-refresh, ce-sessions Domain: ce-frontend-design, ce-dhh-rails-style, ce-agent-native-architecture Research: ce-web-researcher, ce-slack-research, ce-best-practices-researcher Cleanup: ce-simplify-code, ce-clean-gone-branches Other: ce-setup, ce-product-pulse, ce-release-notes, ce-proof, ce-demo-reel, ce-gemini-imagegen, ce-polish-beta, ce-optimize, ce-report-bug, ce-riffrec-feedback-analysis

Always load the skill file before using a skill. The skill files contain the workflow.

The Pet Peeve Rule

It is unacceptable to do the same wrong thing twice. It is unacceptable to push back three or more times on the same problem without searching for the answer. If the agent is going in circles, the answer is always in one of these places, in this order of preference:

1. The installed skills (~/.config/opencode/skills/, .agents/skills/, .claude/skills/)
2. The MD knowledge base (/home/ezalgo/workspace/ezalgoCommandCenter/.hermes/plans/)
3. The Docmost wiki (https://myworkspace-474252.docmost.com/s/ezalgocommandcenter)
4. The project reference docs (.agents/reference/, AGENTS.md, CLAUDE.md)
5. The MCP server tools (context7, sequential-thinking, etc.)
6. Online official documentation

The agent must check these in order before asking Andres to repeat themselves. The friction this prevents: Andres says “search the docs” after an hour of failures. The docs had the answer in 15 seconds. The agent should have looked.

Read Before You Act

When working on a specific domain, read the corresponding reference doc first:

GitNexus — Code Intelligence

This project is indexed by GitNexus as ezalgocommandcenter (44758 symbols, 55598 relationships, 300 execution flows). Use the GitNexus MCP tools to understand code, assess impact, and navigate safely.

If any GitNexus tool warns the index is stale, run npx gitnexus analyze in terminal first.

Always Do

• MUST run impact analysis before editing any symbol. Before modifying a function, class, or method, run gitnexus_impact({target: "symbolName", direction: "upstream"}) and report the blast radius (direct callers, affected processes, risk level) to the user.
• MUST run gitnexus_detect_changes() before committing to verify your changes only affect expected symbols and execution flows.
• MUST warn the user if impact analysis returns HIGH or CRITICAL risk before proceeding with edits.
• When exploring unfamiliar code, use gitnexus_query({query: "concept"}) to find execution flows instead of grepping. It returns process-grouped results ranked by relevance.
• When you need full context on a specific symbol — callers, callees, which execution flows it participates in — use gitnexus_context({name: "symbolName"}).

Never Do

• NEVER edit a function, class, or method without first running gitnexus_impact on it.
• NEVER ignore HIGH or CRITICAL risk warnings from impact analysis.
• NEVER rename symbols with find-and-replace — use gitnexus_rename which understands the call graph.
• NEVER commit changes without running gitnexus_detect_changes() to check affected scope.

Resources

CLI