Meronq
Meronq team

Sprint 1 closed: Canonical Engineering Model wired into handshake

sprint-1cemarchitecturemcphandshake

Sprint 1 is closed.

The goal was to define the first Meronq language primitives — the Canonical Engineering Model (CEM) — that every runtime, memory, scanner, and translator component will share. That vocabulary now exists in code, in tests, and in the handshake AI clients receive at session start.

What Sprint 1 delivered

Every item on the roadmap is checked off:

  • Entity, Relation, Evidence, Event, Action, and Result models in packages/core
  • Factory functions, type guards, and branded IDs
  • First core domain API export from @meronq/core
  • Test suite for primitives and a minimal graph linking example

CEM is defined in ADR-0004 (Accepted). The system vocabulary in ADR-0003 is now Accepted as well.

From types to runtime: handshake + CEM snapshot

Sprint 1 was not only about TypeScript interfaces. Before closing, we addressed seven review gaps so the layer works coherently:

  1. CEM in handshake — handshake now returns a cem block: entities, relations, and evidence built from the workspace (project, apps, packages, ADRs, recent commits).
  2. Fresh sprint hints — recommended_next_steps come from open roadmap tasks (Sprint 2 now).
  3. Single vision source — handshake reads docs/product/vision.md; legacy docs/vision.md redirects.
  4. Portable project path — MERONQ_PATH or auto-discovery via pnpm-workspace.yaml (no hardcoded paths).
  5. Docs aligned — architecture status table, ADR index, first blog post note about sprint scope change.
  6. Social tools isolated — Discord/Telegram/Hashnode/LinkedIn live in an opt-in module, not mixed with core dev tools.
  7. Git write gate — git_add, git_commit, git_push, and git_pull require MERONQ_ALLOW_GIT_WRITE=true.

Local MCP is now v1.10.0. Core dev tools stay on by default; social and git write are explicit opt-in.

What CEM looks like in practice

When an AI client calls handshake, it receives structured CEM data alongside vision and sprint context:

Project (entity)
  ├── contains → apps/local-mcp, apps/web, …
  ├── contains → packages/core, …
  ├── contains → ADR-0004, ADR-0003, …
  └── contains → recent commits
        └── evidence → adr files, commit hashes

This is a read-only snapshot from the repository — not persistent memory yet. It proves the pipeline: engineering artifacts → CEM → AI context.

Persistence, indexing, and translators come next.

Sprint 2 — Local Project Intelligence

Sprint 2 goal: build the first local prototype that can read a project and produce structured project understanding.

Planned work:

  • Define project indexing model
  • Create first CLI prototype (meronq scan, meronq info)
  • Detect package manager, docs, ADRs, apps, and packages
  • Summarize project structure
  • Store project notes locally

The scanner will emit CEM entities; handshake will consume scanner output instead of only listing directory names.

Follow along

Sprint 0 gave us a durable repository. Sprint 1 gave us a shared language. Sprint 2 connects that language to real projects.

← Back to blog