generated from coulomb/repo-seed
Separated open-cmis-tck and guide-board repositories
This commit is contained in:
321
workplans/GUIDE-BOARD-WP-0001-bootstrapping.md
Normal file
321
workplans/GUIDE-BOARD-WP-0001-bootstrapping.md
Normal file
@@ -0,0 +1,321 @@
|
||||
---
|
||||
id: GUIDE-BOARD-WP-0001
|
||||
type: workplan
|
||||
title: "Guide Board Bootstrapping"
|
||||
repo: guide-board
|
||||
domain: markitect
|
||||
status: active
|
||||
owner: codex
|
||||
planning_priority: high
|
||||
planning_order: 1
|
||||
created: "2026-05-07"
|
||||
updated: "2026-05-07"
|
||||
supersedes:
|
||||
- "OPEN-CMIS-TCK-WP-0001"
|
||||
state_hub_workstream_id: "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
|
||||
|
||||
```text
|
||||
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
|
||||
|
||||
```task
|
||||
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
|
||||
|
||||
```task
|
||||
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
|
||||
|
||||
```task
|
||||
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
|
||||
|
||||
```task
|
||||
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
|
||||
|
||||
```task
|
||||
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
|
||||
|
||||
```task
|
||||
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
|
||||
|
||||
```task
|
||||
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
|
||||
|
||||
```task
|
||||
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
|
||||
|
||||
```task
|
||||
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
|
||||
|
||||
```task
|
||||
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
|
||||
|
||||
```task
|
||||
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.
|
||||
Reference in New Issue
Block a user