guide-board/workplans/GUIDE-BOARD-WP-0001-bootstrapping.md

id, type, title, repo, domain, status, owner, planning_priority, planning_order, created, updated, supersedes, state_hub_workstream_id

id	type	title	repo	domain	status	owner	planning_priority	planning_order	created	updated	supersedes	state_hub_workstream_id
GUIDE-BOARD-WP-0001	workplan	Guide Board Bootstrapping	guide-board	markitect	active	codex	high	1	2026-05-07	2026-05-07	OPEN-CMIS-TCK-WP-0001	1d812b7d-74f0-4d71-86a7-0f390b22daf7

GUIDE-BOARD-WP-0001: Guide Board Bootstrapping

Purpose

Rename and reshape the repository from a CMIS-specific TCK harness into guide-board: a certification and compliance preparation framework with extension-based conformance and evidence packs.

The first concrete extension remains open-cmis-tck, but the root project now owns the generic architecture for profiles, checks, evidence, mappings, waivers, reports, retention, and eventual local/containerized operation.

Background

The repository began as open-cmis-tck, a focused CMIS compatibility test facility. That is still valuable, but the larger product opportunity is a generic helper for standards enforcement, certification preparation, compliance readiness, and repository quality management.

Comparable official or authority-backed conformance programs show recurring patterns:

• a source authority and explicit framework version,
• a target or product profile,
• an executable harness, validator, protocol, or procedural test kit,
• setup and preflight requirements,
• raw artifacts and machine-readable results,
• conformance classes, profiles, controls, or requirement mappings,
• challenge, waiver, exclusion, or known-gap handling,
• a clear boundary between self-testing and formal certification.

guide-board should encode those patterns once, while letting extensions provide domain-specific logic.

Target Architecture

authority catalog
  -> extension registry
  -> target profile
  -> assessment profile
  -> preflight checks
  -> runner / validator / evidence collector
  -> raw artifacts
  -> normalized evidence
  -> capability / control / requirement mapping
  -> expectations and waivers
  -> assessment package
  -> reports and exports
  -> retention and trend summaries

Boundary

This project is a preparation and evidence framework. It does not issue certifications, provide audit assurance, replace accredited assessors, replace legal counsel, or redistribute restricted standards and test suites without a license.

D1.1 - Repository Identity

id: GUIDE-BOARD-WP-0001-T001
status: done
priority: high
state_hub_task_id: "77559888-1601-4afb-8370-495365685e22"

Acceptance:

• Root INTENT.md identifies the project as guide-board.
• Root README introduces guide-board and points to the extension model.
• The old CMIS-only framing no longer controls the root project.
• Certification and audit boundaries are explicit.

D1.2 - Extension Layout

id: GUIDE-BOARD-WP-0001-T002
status: done
priority: high
state_hub_task_id: "555d6d5e-5d44-4c48-b409-b86bf5750bca"

Acceptance:

• extensions/open-cmis-tck/INTENT.md exists.
• The CMIS workplan is moved under the extension.
• Extension docs can later be extracted into a separate repository.
• The root project remains extension-neutral.

D1.3 - Candidate Harness Registry

id: GUIDE-BOARD-WP-0001-T003
status: done
priority: high
state_hub_task_id: "35db0770-d081-464f-80a3-7fcb89efdca4"

Acceptance:

• extensions/CANDIDATES.md registers important official or authority-backed harness candidates.
• Candidates include CMIS/OpenCMIS, OGC TEAM Engine, OpenID Foundation Conformance Suite, CNCF Kubernetes Conformance, web-platform-tests, Khronos CTS, NIST ACVP, ONC/HL7 FHIR Inferno, Jakarta EE TCK, OPC UA CTT, NIST SCAP/OpenSCAP, NIST OSCAL, CIS-CAT Pro, and OpenSSF Scorecard.
• Candidate notes capture authority, harness pattern, value, and access constraints.
• Non-harness compliance packs are separated from executable conformance harness candidates.

D1.4 - Core Architecture Blueprint

id: GUIDE-BOARD-WP-0001-T004A
status: done
priority: high
state_hub_task_id: "503cb054-e8a7-42e6-a171-e57c7188d835"

Acceptance:

• docs/ARCHITECTURE-BLUEPRINT.md captures core concepts, precedent lessons, component boundaries, extension archetypes, execution flow, run directory contract, and governance model.
• The blueprint distinguishes executable harnesses, validators, protocol-driven services, hosted suites, repository quality scanners, and procedural evidence collectors.
• The blueprint names the next schema and CLI implementation sequence.

D1.5 - Core Contract Schemas

id: GUIDE-BOARD-WP-0001-T004
status: done
priority: high
state_hub_task_id: "a989702f-cc55-4751-8304-75ee2375f8ec"

Acceptance:

• Define schema drafts for authority metadata, extension manifests, target profiles, assessment profiles, checks, evidence, findings, waivers, mappings, reports, and retention summaries.
• Schemas distinguish executable harnesses, validators, protocol-driven services, and procedural evidence collectors.
• Schemas include source URL, source version, harness version, license/access posture, and certification boundary fields.
• Expectation and waiver set schemas support explicit policy application after findings are generated.

D1.6 - Local CLI Baseline

id: GUIDE-BOARD-WP-0001-T005
status: done
priority: high
state_hub_task_id: "f22f8cc7-27f4-4377-bb61-3e4ac2040475"

Acceptance:

• Provide a local CLI entry point for listing extensions, validating profiles, planning an assessment, running checks, and writing reports.
• CLI operation works before any service API is introduced.
• CLI can execute a no-op/sample extension to prove core contracts independent of CMIS.
• The baseline executor writes the run directory contract, normalized evidence, an assessment package, and a Markdown report.
• The assessment package includes a fingerprinted artifact manifest for runner-emitted raw artifacts.
• The baseline executor applies expectation and waiver policy refs from assessment profiles and reports policy summary counts.
• Failed extension preflight evidence gates downstream check groups so later runners are not invoked against an invalid target posture.

D1.7 - Extension SDK Skeleton

id: GUIDE-BOARD-WP-0001-T006
status: done
priority: high
state_hub_task_id: "3c757929-a5e4-4c11-bbf1-6d7f26def93e"

Acceptance:

• Define how an extension declares metadata, supported frameworks, profile schemas, check groups, runner commands, normalizers, and report fragments.
• Provide a minimal extension template.
• Extension ownership boundaries make later extraction to a separate repository straightforward.
• Python module runner contracts are documented in docs/EXTENSION-SDK.md.
• Manifest-declared command runners execute without shell expansion and return normalized evidence through the same runner result contract.
• Runner artifact refs are constrained to the run directory and fingerprinted in the assessment package artifact manifest.
• Extension-owned mapping sets connect evidence requirement refs to capability, control, conformance, or quality targets.

D1.8 - CMIS Seed Extension Integration

id: GUIDE-BOARD-WP-0001-T007
status: in_progress
priority: high
state_hub_task_id: "455f92b0-1d2b-43d0-aa61-464d9dc83a62"

Acceptance:

• open-cmis-tck runs through the guide-board core contracts rather than a bespoke root-level harness.
• CMIS output normalizes into the same evidence model used by other extensions.
• CMIS capability mappings are extension-owned.

Progress:

• open-cmis-tck declares runner entry points through extension.json.
• The CMIS Browser Binding preflight runner executes through the generic runner bridge and produces normalized evidence.
• The OpenCMIS Java/Maven TCK wrapper executes through the command runner bridge and currently reports dependency or configuration blockers as structured evidence.
• CMIS requirement refs map to extension-owned capability groups in normalized/mappings.json and the Markdown report.
• The core now supports external extension repositories via --extension-dir and GUIDE_BOARD_EXTENSION_PATHS; open-cmis-tck has been split into its own extension repo.

D1.9 - Containerized Execution Design

id: GUIDE-BOARD-WP-0001-T008
status: done
priority: medium
state_hub_task_id: "21e5c1e0-b02e-408d-a657-1771750e9b30"

Acceptance:

• Document a container model that mounts profiles, extension data, credentials, and output directories explicitly.
• Runner images can include extension dependencies without polluting the core.
• Restricted or license-gated harnesses are represented as mounted external assets, not redistributed guide-board content.

Progress:

• Added a dependency-light guide-board-core Containerfile.
• Added .dockerignore to keep local run outputs and development artifacts out of the image build context.
• Added docs/CONTAINER.md with mount contracts for profiles, credentials, runs, and restricted harness assets.
• Documented the extension-specific image path for CMIS Java/Maven/OpenCMIS TCK dependencies.

D1.10 - Optional Local Service API

id: GUIDE-BOARD-WP-0001-T009
status: todo
priority: medium
state_hub_task_id: "58bd6ec6-2cf3-450f-95a7-b695aaf80609"

Acceptance:

• A local API can list extensions, validate profiles, start assessment runs, inspect run status, and fetch reports.
• Long-running jobs are tracked without blocking the API process.
• CLI remains the source of truth for execution semantics.

D1.11 - Compliance Evidence Pack Strategy

id: GUIDE-BOARD-WP-0001-T010
status: todo
priority: medium
state_hub_task_id: "2f845860-ade9-4d31-91c7-cb1c69dc4e1b"

Acceptance:

• Define how non-harness frameworks such as GDPR, SOC 2, HIPAA, NF Z 42-013, NF 461, ISO 14641, and ISO 15489 should be represented.
• Separate official source metadata from internal interpretation.
• Avoid redistributing proprietary standard text.
• Provide a reviewable evidence-request and waiver model suitable for auditor collaboration.

Definition Of Done

• The repository identity is guide-board.
• CMIS is represented as the first extension, not the root product.
• The root architecture is broad enough for official conformance harnesses and procedural evidence packs.
• The root architecture blueprint is documented and linked from README.
• At least one extension can be run through local CLI contracts.
• Candidate extensions are registered with authority, source, access, and architecture notes.
• The project has a clear path from local baseline to containerized service.