Established intent and first workplan

INTENT.md

@@ -0,0 +1,147 @@
+# INTENT
+
+## Project Name
+
+`open-cmis-tck`
+
+## Purpose
+
+`open-cmis-tck` provides a reusable CMIS compatibility test facility as a
+service. Its first target is `kontextual-engine`, but the repository should be
+useful for any CMIS-like repository that wants repeatable capability evidence
+without embedding a Java/Maven TCK harness into the product repository itself.
+
+The project turns CMIS capability claims into evidence:
+
+- execute selected Apache Chemistry OpenCMIS TCK groups against a target access
+  point,
+- capture results in compact machine-readable reports,
+- classify failures by CMIS capability area,
+- distinguish unsupported-by-design behavior from implementation defects,
+- produce scorecard inputs that downstream projects can use for capability
+  planning.
+
+## Product Thesis
+
+CMIS interoperability is most useful when it is honest. A repository does not
+need to support every optional CMIS 1.1 capability, but it must accurately
+advertise what it supports and return stable diagnostics for everything else.
+
+This project exists to make that honesty testable.
+
+## Primary Use Case
+
+Given a running CMIS Browser Binding access point, such as:
+
+```text
+http://127.0.0.1:8000/cmis/compat-tck/browser
+```
+
+the harness should:
+
+1. load a target profile configuration,
+2. run selected OpenCMIS TCK checks,
+3. normalize raw TCK output,
+4. map pass/fail/skip results to capability groups,
+5. write a compact report that can be compared over time,
+6. optionally expose the run and result through a small local service API.
+
+## Intended Users
+
+- Engine developers validating a CMIS adapter.
+- Integration engineers checking a customer repository profile.
+- Product owners tracking CMIS readiness over time.
+- Automated agents that need structured evidence before adjusting a capability
+  scorecard.
+
+## Scope
+
+In scope:
+
+- target profile configuration,
+- OpenCMIS TCK orchestration,
+- deterministic smoke probes for repository info and capability flags,
+- result normalization,
+- capability-group mapping,
+- compact JSON and Markdown reports,
+- service API for starting runs and reading results,
+- historical result retention suitable for trend and scorecard updates,
+- adapters for running against local development services.
+
+Out of scope:
+
+- implementing CMIS server behavior,
+- replacing Apache Chemistry/OpenCMIS,
+- claiming formal certification,
+- embedding target-project domain knowledge into the harness core,
+- requiring every consuming repository to use the same technology stack.
+
+## Boundaries
+
+`open-cmis-tck` is a test facility, not a CMIS implementation.
+
+Target systems own:
+
+- CMIS endpoints,
+- repository data fixtures,
+- authentication and authorization behavior,
+- supported/unsupported capability decisions,
+- product scorecards.
+
+This project owns:
+
+- harness execution,
+- result normalization,
+- capability-group classification,
+- stable reporting contracts,
+- optional local service orchestration.
+
+## First Target Integration
+
+The first target profile is `kontextual-engine` `compat-tck`.
+
+Expected target URL:
+
+```text
+http://127.0.0.1:8000/cmis/compat-tck/browser
+```
+
+Initial expected posture:
+
+- 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.
+
+## Success Criteria
+
+The project is useful when it can:
+
+- run from a clean checkout with documented Java/Maven requirements,
+- verify that a target CMIS endpoint is reachable before invoking the TCK,
+- execute a selected TCK subset against a configured target,
+- produce a normalized result file,
+- map results to capability groups,
+- identify unexpected failures separately from known gaps,
+- support repeated runs without unbounded local data growth,
+- provide enough evidence to update a downstream CMIS capability scorecard.
+
+## Design Principles
+
+- Keep target-specific policy outside the harness core.
+- Make unsupported capabilities explicit and machine-readable.
+- Prefer compact historical records over large raw logs.
+- Preserve raw TCK output as optional artifacts, not the primary interface.
+- Make local development easy before adding distributed execution.
+- Treat score changes as evidence-driven, not aspirational.
+
+## Initial Milestones
+
+1. Repository foundation and target profile schema.
+2. OpenCMIS TCK runner wrapper.
+3. Result normalization and capability mapping.
+4. Kontextual `compat-tck` target profile.
+5. Optional service API for local run orchestration.
+6. Scorecard export contract.