coulomb/open-cmis-tck
Archived
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Restructured as guide-board compliance framework

Browse Source
This commit is contained in:
Bernd Worsch
2026-05-07 09:45:11 +02:00
parent 6108f3ab51
commit 1201695ebe
7 changed files with 744 additions and 148 deletions
Download Patch File Download Diff File Expand all files Collapse all files

259
workplans/GUIDE-BOARD-WP-0001-bootstrapping.md Normal file
View File

@@ -0,0 +1,259 @@
---
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, and OPC UA CTT.
- Candidate notes capture authority, harness pattern, value, and access
constraints.
- Non-harness compliance packs are separated from executable conformance harness
candidates.
## D1.4 - Core Contract Schemas
```task
id: GUIDE-BOARD-WP-0001-T004
status: todo
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.
## D1.5 - Local CLI Baseline
```task
id: GUIDE-BOARD-WP-0001-T005
status: todo
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.
## D1.6 - Extension SDK Skeleton
```task
id: GUIDE-BOARD-WP-0001-T006
status: todo
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.
## D1.7 - CMIS Seed Extension Integration
```task
id: GUIDE-BOARD-WP-0001-T007
status: todo
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.
## D1.8 - Containerized Execution Design
```task
id: GUIDE-BOARD-WP-0001-T008
status: todo
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.
## D1.9 - 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.10 - 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.
- 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.

195
workplans/OPEN-CMIS-TCK-WP-0001-harness-foundation.md
View File

@@ -1,195 +0,0 @@
---
id: OPEN-CMIS-TCK-WP-0001
type: workplan
title: "OpenCMIS TCK Harness Foundation"
repo: open-cmis-tck
domain: markitect
status: active
owner: codex
planning_priority: high
planning_order: 1
created: "2026-05-07"
updated: "2026-05-07"
state_hub_workstream_id: "276483ee-1497-495b-8710-fd8bb7dace22"
---
# OPEN-CMIS-TCK-WP-0001: OpenCMIS TCK Harness Foundation
## Purpose
Establish `open-cmis-tck` as a reusable CMIS compatibility test facility. The
first usable outcome is a local harness that can run selected Apache Chemistry
OpenCMIS TCK checks against a configured CMIS Browser Binding target and produce
normalized capability evidence.
## Background
`kontextual-engine` now exposes a conservative CMIS 1.1 Browser Binding subset
with explicit unsupported flags. Its current scorecard is estimation-based.
Running selected OpenCMIS TCK checks is the next step to turn that estimate into
evidence-backed capability scoring.
This repository keeps the TCK harness separate so product repositories do not
have to carry Java/Maven orchestration, raw TCK output, or test-facility service
code in their own trees.
## Target Architecture
```text
target profile config
-> preflight probe
-> OpenCMIS TCK runner
-> raw run artifacts
-> normalized result model
-> capability-group mapper
-> JSON/Markdown reports
-> optional service API
```
## Boundary
This workplan builds a test facility. It does not implement CMIS server
features, modify `kontextual-engine`, or claim formal CMIS certification.
## D1.1 - Repository Foundation
```task
id: OPEN-CMIS-TCK-WP-0001-T001
status: todo
priority: high
state_hub_task_id: "add6a26d-38a8-4500-8a3e-6fdac43fee42"
```
Acceptance:
- `INTENT.md` captures the project purpose, scope, boundaries, and first target.
- Repository README identifies the project and points to the workplan.
- Basic directory layout exists for configs, scripts, reports, docs, and tests.
- Local generated artifacts are ignored where appropriate.
## D1.2 - Target Profile Schema
```task
id: OPEN-CMIS-TCK-WP-0001-T002
status: todo
priority: high
state_hub_task_id: "2ccc74a7-bed9-4769-8608-d579fdf3a0cd"
```
Acceptance:
- A target profile config format defines endpoint URL, binding, repository ID,
credentials or auth mode, expected capability groups, known gaps, and timeout
settings.
- A `kontextual-engine` `compat-tck` example profile is included.
- Profile validation produces actionable diagnostics for missing or invalid
fields.
## D1.3 - Preflight Probe
```task
id: OPEN-CMIS-TCK-WP-0001-T003
status: todo
priority: high
state_hub_task_id: "6d45885b-78a4-4e8b-8fcc-b8d6488e703b"
```
Acceptance:
- Preflight checks verify target reachability, repository info, CMIS version,
binding posture, and capability flags before invoking the Java TCK.
- Unsupported optional capabilities can be accepted as expected gaps.
- Preflight output is captured as structured JSON.
## D1.4 - OpenCMIS TCK Runner Wrapper
```task
id: OPEN-CMIS-TCK-WP-0001-T004
status: todo
priority: high
state_hub_task_id: "502d7586-6f9e-475e-9683-43260666d5d9"
```
Acceptance:
- The harness documents Java and Maven requirements.
- A runner command can invoke selected OpenCMIS TCK groups against one target.
- Raw logs and machine-readable run metadata are written under a run directory.
- TCK execution can be skipped cleanly when Java/Maven are unavailable.
## D1.5 - Result Normalization
```task
id: OPEN-CMIS-TCK-WP-0001-T005
status: todo
priority: high
state_hub_task_id: "716486b6-6f14-41f8-8417-5015ba746005"
```
Acceptance:
- Raw TCK output is normalized into a stable result schema.
- Results distinguish pass, fail, expected skip, unsupported by design, and
infrastructure error.
- Failures include enough context to map back to TCK group, capability group,
target profile, and raw artifact paths.
## D1.6 - Capability Mapping And Reports
```task
id: OPEN-CMIS-TCK-WP-0001-T006
status: todo
priority: high
state_hub_task_id: "9f7dacc5-4d19-4755-aa9a-8572d4285514"
```
Acceptance:
- Capability-group mapping aligns TCK groups with repository/type, navigation,
object/content, versioning, query, relationships, ACL/policy, change log, and
extension gaps.
- JSON reports are compact and suitable for scorecard ingestion.
- Markdown reports summarize pass/fail/skip counts and unexpected gaps.
- Known gaps do not hide unexpected failures in the same capability area.
## D1.7 - Optional Local Service API
```task
id: OPEN-CMIS-TCK-WP-0001-T007
status: todo
priority: medium
state_hub_task_id: "a05e47bd-88db-4878-aef4-bf328790c3f0"
```
Acceptance:
- A small local API can list target profiles, start a run, inspect run status,
and fetch normalized reports.
- The service is optional; CLI operation remains the primary path.
- Long-running TCK jobs are tracked without blocking the API process.
## D1.8 - Historical Result Retention
```task
id: OPEN-CMIS-TCK-WP-0001-T008
status: todo
priority: medium
state_hub_task_id: "c27ea43f-41ec-49d0-a890-3681455f7c6c"
```
Acceptance:
- The harness keeps compact run summaries over time.
- Retention avoids unbounded raw log growth.
- Summaries are suitable for trend charts and downstream capability-score
updates.
## Definition Of Done
- A developer can configure a target CMIS Browser Binding endpoint.
- Preflight can verify the target before TCK execution.
- Selected OpenCMIS TCK checks can be invoked or cleanly skipped when
dependencies are missing.
- Normalized JSON and Markdown reports are generated.
- The `kontextual-engine` `compat-tck` target profile is represented.
- The repository has a clear path for StateHub registration.