FrontAgent OSS Harness

Documents

1. README.md is the public product and command overview.
2. docs/architecture.md and docs/design.md define architecture and SDD behavior.
3. CONTRIBUTING.md, docs/workflow.md, and docs/knowledge-contract.md define OSS contribution, Harness, and GitNexus contract rules.
4. Issue or PR text defines the specific change request.
5. Existing code is evidence, but it does not override the documents above.

When documents conflict or expected behavior is unclear, ask the maintainer instead of silently choosing a new architecture.

Work

1. Run pnpm agent:bootstrap and pnpm quality:predev before code changes when feasible.
2. Before editing a function, class, or method, run GitNexus impact analysis and report the blast radius.
3. Keep changes focused and independently reviewable.
4. Run focused tests for the touched area, then broader gates as risk increases.
5. Before final review, run pnpm quality:precommit at minimum and use GitNexus detect_changes to inspect the final diff.
6. For critical skeleton changes, fill the PR GitNexus impact summary with concrete detect_changes plus query, context, or impact results.

Harness Loop

For non-trivial repository changes, use this loop:

1. Start from an Issue, Discussion, or maintainer-approved task description.
2. Create a short-lived branch from develop using feat/, fix/, docs/, or chore/.
3. Run pnpm agent:bootstrap and pnpm quality:predev.
4. Implement the smallest reviewable change with focused tests.
5. Run pnpm quality:local before pushing when feasible.
6. Open a PR to develop with the PR template filled in, including the GitNexus impact summary for critical skeleton changes.
7. Wait for GitHub Actions, Contract Guard, Repo Guard, Codex, Copilot, and maintainer review comments.
8. Address actionable review comments with follow-up commits, then rerun the relevant gates.
9. Let maintainers decide merge readiness; do not add comment-triggered auto-merge behavior.

OSS Scope

FrontAgent uses an open-source maintainer workflow. Do not add training-camp claim comments, score labels, progress ledgers, timeout-close automation, or comment-triggered auto-merge rules unless maintainers explicitly request a separate workflow.

GitNexus — Code Intelligence

This project is indexed by GitNexus as FrontAgent (6641 symbols, 13666 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