generated from coulomb/repo-seed
100 lines
5.0 KiB
Markdown
100 lines
5.0 KiB
Markdown
# Orthogonal Successor Roadmap
|
|
|
|
Date: 2026-05-14
|
|
|
|
## Purpose
|
|
|
|
This roadmap explains how `infospace-bench`, `markitect-tool`, and
|
|
`kontextual-engine` should together replace the relevant functionality of the
|
|
original `markitect-project` without recreating a monolith.
|
|
|
|
## Orthogonal Roles
|
|
|
|
| Repository | Layer | Owns | Must not own |
|
|
| --- | --- | --- | --- |
|
|
| `markitect-tool` | Syntax | Markdown parsing, document structure, contracts, validation, references, transformations, local query/cache primitives, CLI/library tooling | Concrete knowledge-space projects, durable operational state, domain workflows |
|
|
| `kontextual-engine` | System | Persistent asset identity, ingestion, metadata, relationships, retrieval, governed transformation, workflow execution, APIs, permissions, auditability | Markdown-specific syntax rules, one domain application, final knowledge-space methodology |
|
|
| `infospace-bench` | Application | Concrete infospaces, artifact manifests, evaluation methodology, inspection reports, reference experiments, applied workflows, migration pilots | Low-level Markdown tooling, general runtime/orchestration platform, reusable engine primitives |
|
|
|
|
## Replacement Principle
|
|
|
|
The old `markitect-project` combined syntax, runtime, application, examples,
|
|
and experiments in one repo. The successor architecture should preserve the
|
|
useful behaviors by relocating them to the correct layer:
|
|
|
|
- Markdown document mechanics move to `markitect-tool`.
|
|
- Persistence, retrieval, orchestration, governance, and agent-safe operations
|
|
move to `kontextual-engine`.
|
|
- Infospace definitions, experiments, quality methodology, concrete pilots,
|
|
and applied inspection workflows live in `infospace-bench`.
|
|
|
|
`infospace-bench` should therefore replace the old infospace feature surface as
|
|
an **application composition** of the two lower layers, not as a direct code
|
|
copy.
|
|
|
|
## Legacy Feature Placement
|
|
|
|
| Old `markitect-project` feature | New home | Notes |
|
|
| --- | --- | --- |
|
|
| Markdown AST parsing and section extraction | `markitect-tool` | `infospace-bench` consumes via adapter. |
|
|
| Entity/relation Markdown shape validation | `markitect-tool` + `infospace-bench` | Generic contract validation in tool; infospace-specific contract selection in bench. |
|
|
| Infospace config and project layout | `infospace-bench` | Concrete application artifact. |
|
|
| Entity and relation domain models | `infospace-bench` | Application-level knowledge semantics. |
|
|
| Collection checks and viability thresholds | `infospace-bench` | Methodology belongs with applied infospaces. |
|
|
| Metrics history and evaluation reports | `infospace-bench` initially; `kontextual-engine` later for durable storage | File-backed first, engine-backed when needed. |
|
|
| Source processing pipelines | `infospace-bench` definitions; `markitect-tool` transforms; `kontextual-engine` orchestration | Keep workflow intent separate from runtime. |
|
|
| LLM-assisted evaluation/generation | `infospace-bench` workflow contracts; provider abstraction outside or lower layer | No vendor lock-in. |
|
|
| Asset identity, provenance, retrieval, workflow runs | `kontextual-engine` | `infospace-bench` should integrate, not reimplement. |
|
|
| Reference experiments such as Wealth of Nations/VSM | `infospace-bench` | Concrete pilot and acceptance corpus. |
|
|
|
|
## Workplan Set
|
|
|
|
The following `infospace-bench` workplans establish the path:
|
|
|
|
1. `IB-WP-0005` — Orthogonal successor architecture and feature map
|
|
2. `IB-WP-0006` — `markitect-tool` adapter and Markdown artifact validation
|
|
3. `IB-WP-0007` — Entity and relation model migration
|
|
4. `IB-WP-0008` — Evaluation history, metrics, and viability parity
|
|
5. `IB-WP-0009` — Applied workflow and generation pipeline
|
|
6. `IB-WP-0010` — `kontextual-engine` integration boundary
|
|
7. `IB-WP-0011` — Pruned legacy reference pilot migration
|
|
8. `IB-WP-0012` — Replacement readiness and CLI parity gate
|
|
|
|
Supporting architecture artifacts:
|
|
|
|
- `docs/legacy-infospace-feature-inventory.md`
|
|
- `docs/successor-boundary-interface-map.md`
|
|
- `docs/replacement-acceptance-matrix.md`
|
|
|
|
## Sequencing
|
|
|
|
```text
|
|
IB-WP-0005
|
|
-> IB-WP-0006
|
|
-> IB-WP-0007
|
|
-> IB-WP-0008
|
|
-> IB-WP-0009
|
|
-> IB-WP-0010
|
|
-> IB-WP-0011
|
|
-> IB-WP-0012
|
|
```
|
|
|
|
The sequence is intentionally conservative: first prove boundaries, then add
|
|
syntax-layer integration, then migrate application semantics, then introduce
|
|
runtime/engine integration and final replacement gates.
|
|
|
|
## Success Criteria
|
|
|
|
The successor split is working when:
|
|
|
|
- `infospace-bench` can run meaningful infospaces without internal Markdown
|
|
parser code.
|
|
- `infospace-bench` can optionally persist and operate infospaces through
|
|
`kontextual-engine` without becoming an engine itself.
|
|
- A pruned legacy MarkiTect infospace can be migrated and evaluated with
|
|
traceable outputs.
|
|
- Users can see which old `markitect-project` infospace commands are replaced,
|
|
reframed, delegated, or intentionally retired.
|
|
- The three repos remain independently understandable from their own
|
|
`INTENT.md` files.
|