info-tech-canon/workplans/ITC-WP-0002-service-surface-cli-json-api.md

id, type, title, repo, status, priority, created, updated, depends_on_workplans

id	type	title	repo	status	priority	created	updated	depends_on_workplans
ITC-WP-0002	workplan	Service Surface Baseline CLI JSON API	info-tech-canon	planned	high	2026-05-23	2026-05-23	ITC-WP-0001

ITC-WP-0002 - Service Surface Baseline CLI JSON API

Goal

Create the first practical service surface for InfoTechCanon: a JSON-oriented CLI, importable Python service layer, and minimal local API from the start.

Intent

The service should use infospace-bench facilities instead of inventing a parallel infospace runtime. The initial surface should be small, explicit, and usable by downstream agents and tools.

Tasks

T01 - Package skeleton

id: ITC-WP-0002-T01
status: planned
priority: high

• Add a minimal Python package for InfoTechCanon service code.
• Add pyproject.toml with local dependency expectations for infospace-bench.
• Keep runtime dependencies narrow.

T02 - CLI commands

id: ITC-WP-0002-T02
status: planned
priority: high

• Add commands that return JSON by default:
  • inspect canon
  • list artifacts
  • list standards
  • list models
  • validate
  • graph
  • profile inspect
• Use structured errors.

T03 - Python service layer

id: ITC-WP-0002-T03
status: planned
priority: high

• Wrap infospace loading, artifact listing, validation, metrics, and graph export behind stable service functions.
• Keep domain-specific canon logic separate from generic infospace-bench logic.

T04 - API baseline

id: ITC-WP-0002-T04
status: planned
priority: high

• Add a minimal local API for read-only canon inspection.
• Endpoints should mirror CLI contracts where practical.
• Prefer JSON responses suitable for agents and tools.
• Defer authentication, remote deployment, and multi-tenant concerns.

Non-Goals

• Do not build a large web application.
• Do not duplicate infospace-bench lifecycle implementation.
• Do not introduce semantic changes to canon documents in this workplan.

Acceptance

• The repo exposes CLI, JSON, and API entry points.
• Commands can inspect the infospace/ root.
• API and CLI outputs share the same service-layer contracts.
• Tests cover the first happy paths and structured failures.