RevoGrid Project – AI Agent Instructions

Scope

These instructions apply to the entire repository.

This repo combines:

• RevoGrid core source in revogrid/
• RevoGrid Pro plugin source in release/plugins/
• Portal and documentation source in src/
• Framework example components in src/components/

Source Of Truth

When answering questions or making suggestions about RevoGrid, plugins, types, rendering, or grid behavior:

1. Look at revogrid/ first. The core grid implementation is the primary source of truth.
2. Look at core types next, especially:
   • revogrid/src/types/interfaces.ts
   • revogrid/src/types/dimension.ts
   • revogrid/src/types/selection.ts
   • revogrid/src/types/plugin.types.ts
3. For Pro behavior and extension patterns, inspect release/plugins/.
4. For framework-specific usage and demos, inspect src/components/.
5. Prefer implementation over docs. If there is any ambiguity, verify in source code.

Repo-Specific Guidance

• Pro plugin implementation lives in release/plugins/.
• release/plugins/index.ts is the central export hub for Pro plugins and related utilities.
• src/components/ contains examples and wrappers used by the docs portal. Treat these as usage references, not the canonical implementation.
• Documentation content under src/content/docs/ is useful for wording and examples, but should not override behavior observed in revogrid/ or release/plugins/.

MCP Usage

• If the RevoGrid MCP service is available, use it early to retrieve the best matching docs, examples, migration notes, Pro/Core feature resolution, and typed plugin context.
• Prefer MCP especially for:
  • finding the closest framework example
  • checking whether a capability is Core or Pro
  • locating the right plugin or editor API before writing code
  • retrieving migration guidance for advanced features
• If Pro access is configured, the hosted endpoint is https://mcp.rv-grid.com/pro.
• MCP is a retrieval aid, not the final authority. Validate any implementation detail that affects behavior against local source code in revogrid/, core types, and release/plugins/.
• If MCP results and local implementation disagree, trust the local implementation in this repository and note the discrepancy.

Change Strategy

When making changes:

1. Determine whether the behavior belongs to core grid logic, a Pro plugin, or only a docs/example layer.
2. Fix the underlying implementation in the correct source folder rather than patching only examples or docs.
3. Keep public types aligned with the implementation when behavior or contracts change.
4. Check existing plugin patterns in release/plugins/ before introducing a new plugin API or structure.
5. Never edit revogrid/ folder repo.

Testing Expectations

Use the existing RevoGrid end-to-end suite when changes affect:

• rendering
• keyboard interaction
• mouse interaction
• editing
• filtering
• sorting
• grouping
• pinning
• virtualization
• export
• lifecycle behavior in the browser

Relevant test locations and commands:

• E2E tests: revogrid/e2e/
• Unit tests: revogrid/test/
• Core unit test command: npm run test from revogrid/
• Core E2E command: npm run test:e2e from revogrid/

If a behavior change touches browser interaction or visual grid state, prefer adding or updating an E2E test in revogrid/e2e/.

Practical Review Order

For most tasks, inspect files in this order:

1. RevoGrid MCP results, if available and relevant
2. revogrid/src/...
3. revogrid/src/types/...
4. release/plugins/...
5. src/components/...
6. src/content/docs/...

Agent Output Quality Bar

• Do not infer grid behavior from docs when the implementation is available.
• Do not treat demo code as the definitive contract.
• When uncertain, cite the exact implementation file that establishes the behavior.
• Keep fixes minimal and aligned with the existing RevoGrid architecture and plugin patterns.