ai-ecosystem-inventory-map

c21.ai-session-map proved that qmap can make one AI agent session legible. What we still do not have is the broader inventory view: a company-wide snapshot that answers:

Which agents were active in this timeframe, what repositories and files are they touching, and what MCP servers, tools, and sub-agents make up that working ecosystem?

This is not just a bigger c21. The semantic structure is different:

• multiple active agents instead of one focal session
• repositories as first-class actors between agents and files
• files that should read as subordinate to repositories
• tools and sub-agents that may share a mesh family while remaining semantically distinct
• dense stress cases that are wider and heavier than the current session fixtures

The planning work for this was captured in design as c43. This cycle brings the actual implementation work into qmap, along with the deterministic synthetic inventory contract needed to tune layout and wrapper behavior locally.

Deliver one runnable qmap experiment plus a narrow public wrapper that:

• expresses the inventory/index semantics using qmap's existing actor families first
• owns a deterministic synthetic scenario suite covering demo through enterprise density
• validates grouping modes that matter for the inventory shape, especially repository readability
• establishes the thinnest stable public seam for later promotion into the design site

• cycles/c25.ai-ecosystem-inventory-map/ — cycle docs and planning
• dev/experiments/c25.ai-ecosystem-inventory-map/ — runnable inventory experiment
• experiment-local synthetic inventory data harness under shared/
• src/components/QMapInventoryIndex.vue — public wrapper with inventory-specific defaults if the seam is clean enough

• cycles/c25.ai-ecosystem-inventory-map/CYCLE.md
• cycles/c25.ai-ecosystem-inventory-map/PLAN.md
• cycles/c25.ai-ecosystem-inventory-map/initial-prompt.md
• dev/experiments/c25.ai-ecosystem-inventory-map/
• src/components/QMapInventoryIndex.vue
• src/components/QMapInventoryIndexDefaults.js

The repo now has a real c25 home, an experiment-local inventory scenario harness, and a lightweight public wrapper seam. The next implementation pass should focus on scene judgment: density, defaults, and whether repository/file relationships stay readable before adding new visual primitives.

• wiring live production inventory data
• inventing new repository, tool, or sub-agent meshes before the wrapper is proven
• creating a design-site route during this cycle
• solving final filtering, summarization, or pagination UX before density pressure is understood

Recommended first-pass actor mapping:

• AI Agents -> agent
• Repositories -> app
• Files -> file
• MCP Servers -> mcp-server
• Tools -> skill
• Sub-Agents -> skill

Semantic meaning rides on tags, not new meshes, for the first pass:

• entityType: 'AI Agent' | 'Repository' | 'File' | 'MCP Server' | 'Tool' | 'Sub-Agent'

Important consequence:

• tools and sub-agents can be separated by grouping and labeling before deciding whether qmap needs dedicated mesh families
• repositories can be proven as app actors before introducing a repository-specific visual primitive

The first experiment must validate at least:

• Entity Type -> level1: 'entityType'
• Repository -> level1: 'entityType', level2: 'repo'
• Team -> level1: 'team'
• Business Unit -> level1: 'businessUnit'
• Flat -> {}

Repository mode is the critical one because it pressure-tests whether repository -> file structure can read clearly without a bespoke nested renderer.

• one qmap experiment convincingly reads as an inventory/index surface rather than a session replay
• repository/file layering remains legible in both teamspace and enterprise
• the synthetic scenario pack supports both screenshots and density tuning
• the wrapper API stays narrow enough to promote later without importing experiment-local files