Separated open-cmis-tck and guide-board repositories

INTENT.md

@@ -1,184 +1,108 @@
 # INTENT
 
-## Project Name
+## Extension Name
+
+`open-cmis-tck`
+
+## Parent Project
 
 `guide-board`
 
 ## Purpose
 
-`guide-board` is a certification and compliance preparation framework. It helps
-teams turn claims about standards support, regulatory posture, and repository
-quality into structured evidence that can be reviewed, repeated, compared, and
-used during assessments.
+`open-cmis-tck` is the first guide-board extension. It provides a reusable CMIS
+compatibility test facility around selected Apache Chemistry OpenCMIS TCK checks.
 
-The project provides the core evidence model, orchestration contracts, extension
-layout, and reporting surface. Domain-specific standards, regulations, and
-conformance tools live in extensions. An extension may wrap an executable test
-harness, validate machine-readable artifacts, guide procedural evidence
-collection, or combine several of those approaches.
+The extension turns CMIS capability claims into guide-board evidence:
 
-The first extension is `open-cmis-tck`, which packages CMIS compatibility testing
-around Apache Chemistry OpenCMIS TCK execution. It is the first concrete use case,
-not the boundary of the project.
+- execute selected OpenCMIS TCK groups against a target access point,
+- capture raw logs and run metadata,
+- normalize results into guide-board-compatible evidence,
+- classify outcomes by CMIS capability area,
+- distinguish unsupported-by-design behavior from implementation defects,
+- produce scorecard and assessment inputs for downstream projects.
 
-`guide-board` does not issue certifications, provide audit assurance, replace
-legal counsel, or act as a certification body. It supports preparation and
-execution by making evidence, assumptions, gaps, and mappings explicit.
+## Boundary
 
-## Product Thesis
+This extension is a test facility, not a CMIS implementation and not a
+certification authority. It does not implement server behavior, replace the CMIS
+specification, or claim formal certification.
 
-Compliance work is useful when it is evidence-driven, source-aware, and honest
-about uncertainty. A team should be able to say what it claims, which authority or
-standard that claim comes from, what evidence supports it, which gaps are known,
-which checks were not applicable, and which conclusions still require human or
-accredited review.
+Target systems own:
 
-`guide-board` exists to make that process repeatable.
+- CMIS endpoints,
+- repository data fixtures,
+- authentication and authorization behavior,
+- supported and unsupported capability decisions,
+- product scorecards.
+
+This extension owns:
+
+- target profile shape for CMIS Browser Binding checks,
+- CMIS preflight probes,
+- OpenCMIS TCK orchestration,
+- CMIS result normalization,
+- CMIS capability mapping,
+- guide-board report fragments.
 
 ## Primary Use Case
 
-Given a target system or repository, a selected assessment profile, and one or
-more extensions, `guide-board` should:
+Given a running CMIS Browser Binding access point, such as:
 
-1. load target and assessment profile configuration,
-2. resolve the relevant extension and authority metadata,
-3. run preflight checks before expensive or regulated checks,
-4. execute harnesses, validators, or evidence collection steps,
-5. preserve raw artifacts where useful,
-6. normalize results into a stable evidence model,
-7. map evidence to capabilities, controls, conformance classes, or requirements,
-8. distinguish pass, fail, expected gap, waiver, unsupported by design, and
-   infrastructure error,
-9. write compact JSON and Markdown assessment reports,
-10. retain run summaries for comparison over time.
+```text
+http://127.0.0.1:8000/cmis/compat-tck/browser
+```
 
-## Intended Users
+the extension should:
 
-- Engineering teams preparing technical conformance evidence.
-- Product owners tracking certification and compliance readiness.
-- Compliance and quality teams coordinating evidence across repositories.
-- Integration teams validating customer or partner systems against declared
-  standards.
-- Automated agents that need structured evidence before changing scorecards,
-  release gates, or repository quality posture.
+1. load a CMIS target profile,
+2. verify target reachability and repository posture,
+3. run selected OpenCMIS TCK checks,
+4. normalize raw TCK output,
+5. map pass, fail, skip, expected gap, and infrastructure outcomes to CMIS
+   capability groups,
+6. write guide-board-compatible JSON and Markdown reports.
 
-## Core Concepts
+## First Target Integration
 
-- Authority: the standards body, regulator, certification program, or project
-  that defines requirements or tests.
-- Framework: a named standard, regulation, profile, certification program, or
-  quality policy.
-- Extension: a domain-specific package that knows how to gather and normalize
-  evidence for one framework or family of frameworks.
-- Target profile: the system, repository, service, artifact, or process being
-  assessed.
-- Check: an executable, validator, probe, manual evidence request, or procedural
-  step.
-- Evidence: raw and normalized material produced by a check.
-- Mapping: the relationship between evidence and a capability, control,
-  conformance class, requirement, or scorecard dimension.
-- Expectation: a declared posture for an optional capability, known gap, accepted
-  risk, or unsupported-by-design feature.
-- Waiver: a time-bounded and reviewable exception that prevents expected gaps from
-  hiding unexpected failures.
-- Assessment package: the normalized result set, human report, source metadata,
-  raw artifact pointers, and decision boundary.
+The first target profile is `kontextual-engine` `compat-tck`.
 
-## Extension Model
+Expected target URL:
 
-Extensions live under `extensions/<extension-id>/` while incubating in this
-repository. Each extension should have its own `INTENT.md` so it can later become
-a separate repository without losing product boundaries.
+```text
+http://127.0.0.1:8000/cmis/compat-tck/browser
+```
 
-An extension may provide:
+Initial expected posture:
 
-- source and authority metadata,
-- target profile schemas,
-- harness installation notes,
-- preflight probes,
-- runners or validator adapters,
-- normalization rules,
-- control or capability mappings,
-- report fragments,
-- workplans,
-- sample profiles and fixtures.
+- selected repository/type checks should pass,
+- selected object/content checks should pass,
+- navigation, query, ACL, and versioning checks may partially pass,
+- AtomPub and Web Services are not target bindings,
+- unsupported optional capabilities should be treated as expected skips or
+  explained gaps, not failures by default.
 
-The core must stay extension-neutral. It should know how to orchestrate,
-normalize, map, retain, and report evidence, but it should not embed CMIS,
-healthcare, identity, geospatial, cryptographic, privacy, or records-management
-policy directly.
+## Source Posture
 
-## Scope
+The extension should track source authority and maintenance status explicitly.
+Apache Chemistry OpenCMIS provides TCK package APIs and Maven artifacts, but the
+Apache Chemistry project appears retired. The extension must therefore preserve
+harness version metadata and avoid overstating the meaning of a TCK pass.
 
-In scope:
+Useful sources:
 
-- extension registry and lifecycle,
-- target and assessment profile contracts,
-- authority and source metadata,
-- check orchestration,
-- local CLI-first execution,
-- optional service API for local or containerized operation,
-- normalized evidence, finding, waiver, and report schemas,
-- compact historical result retention,
-- extension adapters for official or widely used conformance harnesses,
-- procedural evidence packs for frameworks that do not have official executable
-  test harnesses.
-
-Out of scope:
-
-- issuing certifications,
-- claiming audit assurance,
-- replacing accredited certification bodies or qualified auditors,
-- replacing legal, privacy, security, or records-management counsel,
-- redistributing proprietary standards text or restricted test suites without a
-  license,
-- hiding source/version uncertainty,
-- embedding target-project domain knowledge in the core.
-
-## First Extension
-
-The first extension is `extensions/open-cmis-tck/`.
-
-It should wrap selected Apache Chemistry OpenCMIS TCK checks against a configured
-CMIS Browser Binding endpoint, normalize the output, map results to CMIS
-capability groups, and produce guide-board-compatible evidence reports.
-
-## Initial Candidate Families
-
-Initial candidate extensions are registered in `extensions/CANDIDATES.md`. They
-include official or authority-backed conformance harness patterns from OGC, the
-OpenID Foundation, CNCF Kubernetes, W3C/WHATWG 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, OpenSSF Scorecard, and CMIS/OpenCMIS.
-
-The point of studying these candidates is not to implement everything at once. It
-is to make the core architecture fit the real shapes of conformance work:
-profile selection, source versioning, harness setup, raw artifact retention,
-normalization, requirement mapping, challenge/waiver handling, and certification
-submission boundaries.
+- [Apache Chemistry OpenCMIS TCK package](https://chemistry.apache.org/java/javadoc/org/apache/chemistry/opencmis/tck/package-summary.html)
+- [Maven Central artifact](https://central.sonatype.com/artifact/org.apache.chemistry.opencmis/chemistry-opencmis-test-tck)
 
 ## Success Criteria
 
-`guide-board` is useful when it can:
+The extension is useful when it can:
 
-- run from a clean checkout with a documented local baseline,
-- register extensions without changing core code,
-- run at least one extension end to end,
-- preserve raw evidence without making raw logs the primary interface,
-- produce compact machine-readable and human-readable reports,
+- run from a clean checkout with documented Java/Maven requirements,
+- validate a CMIS Browser Binding target before TCK execution,
+- execute or cleanly skip selected OpenCMIS TCK groups,
+- preserve raw TCK output as optional artifacts,
+- emit normalized guide-board evidence,
+- map results to CMIS capability groups,
 - identify expected gaps separately from unexpected failures,
-- track authority names, framework versions, harness versions, and source links,
-- support later containerized execution without changing assessment contracts,
-- help teams prepare for certifications and compliance assessments without
-  overstating what the tool itself can certify.
-
-## Design Principles
-
-- Keep the core small, boring, and extension-neutral.
-- Treat official source metadata as part of the evidence.
-- Make unsupported or untested areas explicit.
-- Prefer local, inspectable execution before distributed service operation.
-- Preserve raw artifacts by reference, not as the main product interface.
-- Separate evidence collection from certification conclusions.
-- Design for both executable harnesses and procedural compliance evidence.
-- Make later extension extraction to separate repositories straightforward.
+- provide enough evidence to update downstream CMIS capability scorecards.