State-hub connect and initial workplans

.claude/rules/architecture.md

@@ -0,0 +1,20 @@
+# Architecture Notes
+
+The intended architecture is layered:
+
+```text
+markitect-tool     -> syntax layer
+kontextual-engine  -> system/runtime layer
+infospace-bench    -> application layer
+```
+
+The first implementation should establish repo shape before service shape:
+
+- `infospaces/` for concrete infospace projects
+- `schemas/` or dependency references for artifact schemas
+- `workflows/` for application-level workflow definitions
+- `reports/` for evaluation and inspection outputs
+- `docs/` for migration and design records
+
+Use direct dependencies on lower-layer projects only where they clarify the
+boundary. Avoid copying infrastructure wholesale from `markitect-main`.

.claude/rules/repo-boundary.md

@@ -0,0 +1,19 @@
+# Repo Boundary
+
+`infospace-bench` owns application-level infospace usage. It must not absorb
+lower-layer responsibilities.
+
+Belongs here:
+
+- Infospace definitions and examples
+- Application workflow definitions
+- Evaluation and inspection reports
+- Migration notes from `markitect-main`
+- Workplans for applied infospace capabilities
+
+Belongs elsewhere:
+
+- Markdown parsing and structural syntax primitives: `markitect-tool`
+- Runtime persistence and orchestration: `kontextual-engine`
+- LLM provider abstraction: `llm-connect` or equivalent
+- Final production domain artifacts: the relevant domain repo

.claude/rules/repo-identity.md

@@ -0,0 +1,11 @@
+# Repo Identity
+
+- Project: `infospace-bench`
+- Domain: `markitect`
+- State Hub repo slug: `infospace-bench`
+- State Hub topic ID: `5571d954-0d30-4950-980d-7bcaaad8e3e2`
+- Purpose: application-layer workspace and service for concrete infospaces.
+
+This repo is a scoped successor to the application-level infospace work in
+`markitect-main`. It should preserve and extend the parts that help create,
+evaluate, inspect, and evolve real knowledge spaces.

.claude/rules/session-protocol.md

@@ -0,0 +1,8 @@
+# Session Protocol
+
+1. Read `SCOPE.md`, `INTENT.md`, and the active workplan before making changes.
+2. Check `git status --short` and preserve user changes.
+3. Use State Hub as the coordination record when available.
+4. Keep repo artifacts traceable: workplans, docs, configs, metrics, and outputs
+   should explain what changed and why.
+5. Prefer narrow, inspectable changes over broad platform work.

.claude/rules/stack-and-commands.md

@@ -0,0 +1,17 @@
+# Stack And Commands
+
+The implementation stack is not established yet. Until it is, prefer
+documentation and small scaffold changes over choosing frameworks prematurely.
+
+Useful commands:
+
+```bash
+git status --short
+rg --files
+```
+
+State Hub registration was completed with:
+
+```bash
+/home/worsch/the-custodian/state-hub/.venv/bin/custodian register-project --domain markitect --path /home/worsch/infospace-bench
+```

.claude/rules/workplan-convention.md

@@ -0,0 +1,9 @@
+# Workplan Convention
+
+- Workplans live in `workplans/`.
+- Prefix new workplans with `IB-WP-`.
+- Use YAML frontmatter with `id`, `type`, `title`, `domain`, `repo`, `status`,
+  `owner`, `topic_slug`, `created`, and `updated`.
+- Include task blocks with stable IDs, status, priority, and optional State Hub
+  task IDs.
+- Keep workplans tied to this repo's PRD/FRS requirements and State Hub context.

CLAUDE.md

@@ -0,0 +1,7 @@
+@SCOPE.md
+@.claude/rules/repo-identity.md
+@.claude/rules/session-protocol.md
+@.claude/rules/workplan-convention.md
+@.claude/rules/repo-boundary.md
+@.claude/rules/architecture.md
+@.claude/rules/stack-and-commands.md

README.md

@@ -1,3 +1,18 @@
-# repo-seed
+# infospace-bench
 
-A git repository template to bootstrap coulomb projects from.
+Workspace and service for creating, developing, evaluating, and inspecting
+structured knowledge spaces.
+
+This repo is the application-layer successor for the infospace work that began
+inside `markitect-main`. It focuses on concrete infospaces and their lifecycle,
+while lower-level markdown tooling and runtime orchestration remain in sibling
+projects.
+
+Start with:
+
+- `INTENT.md`
+- `wiki/ProductRequirementsDocument.md`
+- `wiki/FunctionalRequirementsSpecification.md`
+- `SCOPE.md`
+- `docs/markitect-main-scope-assessment.md`
+- `workplans/`

SCOPE.md

@@ -0,0 +1,88 @@
+# SCOPE
+
+> This file helps humans and agents quickly understand what this repository is
+> for, when it is relevant, and where its boundaries are.
+
+---
+
+## One-liner
+
+Application-layer workspace and service for building, evaluating, inspecting,
+and evolving concrete structured knowledge spaces.
+
+---
+
+## Core Idea
+
+`infospace-bench` turns the infospace ideas that emerged in `markitect-main`
+into a focused successor project. It should host real infospaces, their
+configuration, evaluation runs, inspection outputs, workflow traces, and export
+experiments.
+
+The repo is intentionally above the lower layers:
+
+- `markitect-tool` owns markdown syntax and document transformation primitives.
+- `kontextual-engine` owns persistence, orchestration, and runtime system
+  concerns.
+- `infospace-bench` owns concrete applied knowledge spaces and their lifecycle.
+
+---
+
+## In Scope
+
+- Defining infospaces as first-class, inspectable project artifacts
+- Populating infospaces from real sources and domain-specific configurations
+- Evaluating entity quality, collection quality, structure, and viability
+- Inspecting relationships, provenance, metrics history, and workflow outputs
+- Running application-level generation, transformation, and analysis workflows
+- Capturing reusable patterns that may later move into lower-layer repos
+
+---
+
+## Out of Scope
+
+- Low-level markdown parsing, schema syntax primitives, or rendering engines
+- Generic persistence infrastructure or workflow orchestration platforms
+- General content management, publishing, or WYSIWYG editing
+- Reusable libraries that belong in `markitect-tool` or `kontextual-engine`
+- Silent coupling to a single LLM vendor or runtime
+
+---
+
+## Relevant When
+
+- A real corpus, book, project, or organization needs an explicit infospace
+- Knowledge artifacts need systematic evaluation and iteration history
+- Relationship structure and quality metrics need to be inspected over time
+- Agent-assisted knowledge development needs scoped project context
+- A MarkiTect infospace experiment needs to be migrated or reimplemented
+
+---
+
+## Not Relevant When
+
+- The work is only markdown syntax manipulation
+- The work is engine/runtime infrastructure
+- A finalized domain repository should own the production artifact
+- A few simple documents only need ordinary editing
+
+---
+
+## Current State
+
+- Status: newly bootstrapped successor repo
+- Source intent: `INTENT.md`, PRD, and FRS in `wiki/`
+- Upstream comparison target: `/home/worsch/markitect-main`
+- State Hub registration: `infospace-bench` under the `markitect` domain
+- First workplans: lifecycle scaffold, MarkiTect migration triage, evaluation
+  framework, and reference infospace pilot
+
+---
+
+## Getting Oriented
+
+- Start with: `INTENT.md`, `wiki/ProductRequirementsDocument.md`,
+  `wiki/FunctionalRequirementsSpecification.md`
+- Migration assessment: `docs/markitect-main-scope-assessment.md`
+- Workplans: `workplans/`
+- State Hub rules: `CLAUDE.md` and `.claude/rules/`

docs/markitect-main-scope-assessment.md

@@ -0,0 +1,116 @@
+# MarkiTect Main Scope Assessment
+
+Date: 2026-05-03
+
+## Purpose
+
+This assessment compares `/home/worsch/markitect-main` against the
+`infospace-bench` intent, PRD, and FRS. It identifies which ideas should be
+migrated, reimplemented, referenced, or deliberately left behind.
+
+## Summary
+
+`markitect-main` already contains substantial infospace work, but it is bundled
+with responsibilities that this repo explicitly excludes: markdown parsing,
+schema tooling, rendering, asset management, GraphQL experiments, prompt
+runtime infrastructure, and broad platform behavior.
+
+`infospace-bench` should therefore become a focused successor for the
+application-layer infospace lifecycle. The right move is selective
+reimplementation and migration of concepts, examples, tests, and documentation,
+not a package copy.
+
+## Source Areas Reviewed
+
+| MarkiTect area | Assessment | Successor action |
+| --- | --- | --- |
+| `markitect/infospace/` | Closest match. Contains entity metadata, config, evaluation, collection checks, history, composition, relation parsing, graph export, and CLI glue. | Reimplement as the first functional baseline, adapting boundaries to lower-layer deps. |
+| `examples/infospace-with-history/` | Strong reference experiment with `infospace.yaml`, source corpus, pipeline stages, viability thresholds, outputs, and metrics methodology. | Migrate as a reference pilot after pruning generated bulk and documenting provenance. |
+| `docs/infospace-primitives.md` | Useful conceptual reference for topic, discipline, entity, evaluation, viability, checks, history, and composition. | Rewrite into this repo's docs with updated architecture terms. |
+| `markitect/prompts/` | Provides generation workflow, dependency resolution, quality gates, traceability, and batch execution. | Reimplement only workflow-facing contracts; runtime/provider mechanics belong outside or behind adapters. |
+| `markitect/analysis/graph.py` and relationship exports | Relevant for inspection and visualization. | Keep graph/relationship inspection as an application feature; rely on lower layers for reusable primitives where possible. |
+| `markitect/schema/` and legacy schema modules | Useful as input constraints, but lower-level schema tooling is out of scope. | Reference or depend on schema tooling; do not copy wholesale. |
+| `markitect/packaging/transclusion/` and `markitect/spaces/transclusion/` | Useful conceptually for composed artifacts, but implementation is syntax/tooling heavy. | Treat as dependency or later integration point, not first migration. |
+| `markitect/assets/`, rendering plugins, static assets | Mostly outside current PRD/FRS except exported artifacts. | Leave behind unless a concrete infospace export needs assets. |
+| GraphQL/server experiments | Platform/API layer not validated for this repo. | Defer. Start with CLI/service contracts only after the domain model is stable. |
+
+## In-Scope Concepts To Carry Forward
+
+- `infospace.yaml` as a declarative project artifact
+- Topic, discipline binding, entity, relation, evaluation, and viability
+- Entity parsing into structured metadata
+- Collection checks: redundancy, coverage, coherence, consistency, granularity
+- Metrics history and snapshot diffs
+- Viability thresholds as explicit acceptance criteria
+- Relationship graph export and inspection
+- Reference corpus workflow: sources -> analyses -> entities -> mappings ->
+  evaluations -> reports
+- Pipeline definitions that are inspectable and reproducible
+
+## Reimplementation Boundaries
+
+The successor should reimplement interfaces around these concepts, but with
+cleaner responsibility boundaries:
+
+- Markdown parsing should come from `markitect-tool` or a thin adapter.
+- Persistence and long-running workflow orchestration should come from
+  `kontextual-engine`.
+- LLM calls should use `llm-connect` or an equivalent provider adapter.
+- This repo should own concrete configuration, project layout, reports,
+  fixtures, workflow definitions, and application-level glue.
+
+## Initial Architecture Recommendation
+
+Start with a file-backed baseline before adding a service:
+
+```text
+infospaces/<slug>/infospace.yaml
+infospaces/<slug>/artifacts/
+infospaces/<slug>/output/
+workflows/
+reports/
+docs/
+```
+
+Then add a small CLI around the FRS lifecycle:
+
+- `create`
+- `load` / `inspect`
+- `add-artifact`
+- `evaluate`
+- `check`
+- `export`
+
+Only introduce a service/API when there is a concrete need for long-running
+state, external consumers, or integration with `kontextual-engine`.
+
+## Migration Priority
+
+1. Documentation and repo shape
+2. Infospace config and artifact model
+3. Evaluation output and metrics history
+4. Collection checks and relationship inspection
+5. Reference infospace pilot
+6. Workflow execution and AI-assisted generation
+7. Service/API layer
+
+## Non-Migration List
+
+Do not migrate these directly into `infospace-bench`:
+
+- General markdown parser/serializer modules
+- Schema generator/validator libraries as reusable tooling
+- Asset management subsystem
+- Rendering/plugin infrastructure
+- GraphQL platform experiments
+- Database and orchestration infrastructure
+- Legacy compatibility layers
+
+## Open Questions
+
+- Should `infospace-bench` depend directly on local sibling repos during early
+  development, or use published/package boundaries from the start?
+- Which reference infospace should be the first maintained pilot: the existing
+  Wealth of Nations/VSM experiment, or a smaller purpose-built corpus?
+- Should State Hub track each infospace as its own workstream once the repo
+  model exists?

workplans/IB-WP-0001-state-hub-and-repo-bootstrap.md

@@ -0,0 +1,88 @@
+---
+id: IB-WP-0001
+type: workplan
+title: "State Hub And Repo Bootstrap"
+domain: markitect
+repo: infospace-bench
+status: active
+owner: markitect
+topic_slug: markitect
+created: "2026-05-03"
+updated: "2026-05-03"
+state_hub_workstream_slug: "repo-integration-infospace-bench"
+state_hub_workstream_id: "35666029-168e-4d8c-b6ce-24cb5a290156"
+---
+
+# IB-WP-0001 — State Hub And Repo Bootstrap
+
+## Goal
+
+Establish `infospace-bench` as a registered, navigable State Hub project with
+clear scope, agent rules, and initial planning artifacts.
+
+## Context
+
+The repo was registered with State Hub under the `markitect` domain. The
+registration created an onboarding workstream and a temporary
+`CLAUDE.custodian.md` suggestion file. The suggestion referenced deprecated
+template behavior, so this repo provides its own minimal integration files.
+
+## Tasks
+
+### T01 — Register repo in State Hub
+
+```task
+id: IB-WP-0001-T01
+status: done
+priority: high
+state_hub_task_id: "7ef38fac-7db0-4368-bab3-4126bf4c0338"
+```
+
+- Registered repo slug `infospace-bench`
+- Domain: `markitect`
+- Topic ID: `5571d954-0d30-4950-980d-7bcaaad8e3e2`
+- Onboarding workstream: `repo-integration-infospace-bench`
+
+### T02 — Add agent orientation files
+
+```task
+id: IB-WP-0001-T02
+status: done
+priority: high
+state_hub_task_id: "54dec019-76a9-4397-9cda-ae9b6cd56926"
+```
+
+- Add `SCOPE.md`
+- Add `CLAUDE.md`
+- Add `.claude/rules/` integration notes
+
+### T03 — Capture migration assessment
+
+```task
+id: IB-WP-0001-T03
+status: done
+priority: high
+state_hub_task_id: "110422cc-85cd-4668-8e99-1fe820357148"
+```
+
+- Compare `markitect-main` against `infospace-bench` PRD/FRS
+- Document migrate/reimplement/defer boundaries
+
+### T04 — Replace temporary custodian suggestion
+
+```task
+id: IB-WP-0001-T04
+status: done
+priority: medium
+state_hub_task_id: "d37306b2-29a8-4439-aa89-754db603dbc5"
+```
+
+- Delete `CLAUDE.custodian.md` after integration is complete
+- Verify `git status --short`
+
+## Acceptance
+
+- State Hub registration exists
+- Repo contains orientation and workplan artifacts
+- Migration scope is documented
+- Temporary registration suggestion is removed

workplans/IB-WP-0002-infospace-lifecycle-baseline.md

@@ -0,0 +1,90 @@
+---
+id: IB-WP-0002
+type: workplan
+title: "Infospace Lifecycle Baseline"
+domain: markitect
+repo: infospace-bench
+status: planned
+owner: markitect
+topic_slug: markitect
+created: "2026-05-03"
+updated: "2026-05-03"
+state_hub_workstream_slug: "ib-wp-0002-infospace-lifecycle-baseline"
+state_hub_workstream_id: "b5972baf-1fb4-4375-a8e3-6e6d6d6fb97c"
+---
+
+# IB-WP-0002 — Infospace Lifecycle Baseline
+
+## Goal
+
+Implement the first file-backed baseline for creating, loading, updating,
+inspecting, and exporting infospaces.
+
+## FRS Coverage
+
+- FR-001 to FR-004: infospace lifecycle
+- FR-010 to FR-012: knowledge artifact population
+- FR-020 to FR-021: structure and relationships
+- FR-070 to FR-071: export and derived artifacts
+- FR-090 to FR-091: structured errors and explicit failures
+
+## Tasks
+
+### T01 — Define repo-local infospace layout
+
+```task
+id: IB-WP-0002-T01
+status: todo
+priority: high
+state_hub_task_id: "c8aaa52e-db89-42e3-9ebc-cb89be3f4d30"
+```
+
+- Define `infospaces/<slug>/infospace.yaml`
+- Define artifact, output, evaluation, metrics, and report directories
+- Document required and optional files
+
+### T02 — Define configuration model
+
+```task
+id: IB-WP-0002-T02
+status: todo
+priority: high
+state_hub_task_id: "a96c3439-89e4-40d0-8731-fe6b39a8f451"
+```
+
+- Reimplement the useful `markitect/infospace/config.py` concepts
+- Keep references to schemas, workflows, sources, disciplines, and viability
+  thresholds explicit
+- Avoid importing runtime orchestration concerns
+
+### T03 — Implement artifact model and loader
+
+```task
+id: IB-WP-0002-T03
+status: todo
+priority: high
+state_hub_task_id: "36ad8a84-f4fd-48ca-bc6f-94827ac03481"
+```
+
+- Model artifact identity, source path, type, provenance, and relationships
+- Support deterministic loading from file-backed projects
+- Return structured errors for invalid layouts
+
+### T04 — Add lifecycle CLI
+
+```task
+id: IB-WP-0002-T04
+status: todo
+priority: medium
+state_hub_task_id: "bfa70d92-c896-4133-8b93-0ece3e53c649"
+```
+
+- Provide minimal commands for create, inspect, add-artifact, and export
+- Keep command outputs scriptable and traceable
+
+## Acceptance
+
+- A new infospace can be created from a template
+- An existing infospace can be loaded and inspected
+- Artifacts can be added and listed
+- Invalid configs produce structured, visible errors

workplans/IB-WP-0003-evaluation-and-inspection.md

@@ -0,0 +1,86 @@
+---
+id: IB-WP-0003
+type: workplan
+title: "Evaluation And Inspection Framework"
+domain: markitect
+repo: infospace-bench
+status: planned
+owner: markitect
+topic_slug: markitect
+created: "2026-05-03"
+updated: "2026-05-03"
+state_hub_workstream_slug: "ib-wp-0003-evaluation-and-inspection"
+state_hub_workstream_id: "bc368ba0-9fd7-4821-a5d7-e5c301faa80a"
+---
+
+# IB-WP-0003 — Evaluation And Inspection Framework
+
+## Goal
+
+Reestablish infospace quality evaluation and inspection as first-class
+application behavior.
+
+## FRS Coverage
+
+- FR-030 to FR-032: evaluation and quality assessment
+- FR-040 to FR-042: inspection, exploration, and visualization
+- FR-080 to FR-081: optional AI-assisted operations and context provision
+
+## Tasks
+
+### T01 — Port evaluation result concepts
+
+```task
+id: IB-WP-0003-T01
+status: todo
+priority: high
+state_hub_task_id: "9bab4b20-3fef-469e-9ce2-f0db3e05e26a"
+```
+
+- Reimplement score entries, entity evaluations, metric values, snapshots, and
+  diffs from `markitect/infospace/evaluation.py`
+- Keep serialization simple and inspectable
+
+### T02 — Rebuild collection checks
+
+```task
+id: IB-WP-0003-T02
+status: todo
+priority: high
+state_hub_task_id: "ee335d74-5be3-4b94-91e3-509486909f93"
+```
+
+- Recreate redundancy, coverage, coherence, consistency, and granularity checks
+- Keep dependencies explicit for embeddings and relationship graphs
+- Write results to reusable structured outputs
+
+### T03 — Add viability evaluation
+
+```task
+id: IB-WP-0003-T03
+status: todo
+priority: high
+state_hub_task_id: "d46b3429-37ef-4375-96e1-304eabf2cc13"
+```
+
+- Compare latest metrics to `infospace.yaml` thresholds
+- Report pass/fail per threshold and overall viability
+
+### T04 — Add relationship inspection output
+
+```task
+id: IB-WP-0003-T04
+status: todo
+priority: medium
+state_hub_task_id: "de4f45e4-81a1-4ddb-98de-15e99ed5605a"
+```
+
+- Export relationship summaries and graph representations
+- Support at least one textual output and one graph-friendly output
+
+## Acceptance
+
+- Evaluation outputs are structured and diffable
+- Collection-level metrics can be produced for a sample infospace
+- Viability can be computed from declared thresholds
+- Relationship structure is inspectable without hidden state

workplans/IB-WP-0004-reference-infospace-pilot.md

@@ -0,0 +1,81 @@
+---
+id: IB-WP-0004
+type: workplan
+title: "Reference Infospace Pilot"
+domain: markitect
+repo: infospace-bench
+status: planned
+owner: markitect
+topic_slug: markitect
+created: "2026-05-03"
+updated: "2026-05-03"
+state_hub_workstream_slug: "ib-wp-0004-reference-infospace-pilot"
+state_hub_workstream_id: "8940a180-646a-4b20-b41f-c56719adfb0e"
+---
+
+# IB-WP-0004 — Reference Infospace Pilot
+
+## Goal
+
+Create the first maintained reference infospace in this repo, using
+`markitect-main/examples/infospace-with-history/` as the primary migration
+candidate.
+
+## Tasks
+
+### T01 — Decide pilot corpus scope
+
+```task
+id: IB-WP-0004-T01
+status: todo
+priority: high
+state_hub_task_id: "5042482f-a14c-4ae5-8d1a-19039dc97010"
+```
+
+- Choose between a small purpose-built corpus and a pruned Wealth of
+  Nations/VSM corpus
+- Record the decision in `docs/`
+
+### T02 — Migrate configuration and methodology
+
+```task
+id: IB-WP-0004-T02
+status: todo
+priority: high
+state_hub_task_id: "a0909309-775b-4220-94f5-6ca811d44caf"
+```
+
+- Adapt `infospace.yaml`
+- Bring over metrics methodology and tutorial material where still valid
+- Remove generated output bulk unless needed as fixtures
+
+### T03 — Define source provenance and artifact policy
+
+```task
+id: IB-WP-0004-T03
+status: todo
+priority: medium
+state_hub_task_id: "10c001a3-ce42-4f1b-8b9a-9965844a94cb"
+```
+
+- Record source origin, license/public-domain status where applicable, and
+  transformation history expectations
+- Decide which generated outputs are committed versus regenerated
+
+### T04 — Run first baseline evaluation
+
+```task
+id: IB-WP-0004-T04
+status: todo
+priority: medium
+state_hub_task_id: "b5e43c2a-b29c-4cb6-b33c-b4db631d0079"
+```
+
+- Execute lifecycle and evaluation baseline from IB-WP-0002 and IB-WP-0003
+- Save reports under the pilot infospace output structure
+
+## Acceptance
+
+- A concrete infospace exists in `infospaces/`
+- The pilot demonstrates lifecycle, evaluation, and inspection behavior
+- Migration from `markitect-main` is traceable and intentionally scoped