tegwick
7249c6a403
- history/2026-08-22-concept-assessment-swot.md: SWOT assessment of the concept corpus with recommendations for the first workplan - statehub register: infotech domain, TD-WP prefix, generated AGENTS.md, .custodian-brief.md and TD-WP-0001 bootstrap workplan - .repo-classification.yaml: category research, domain infotech - SCOPE.md rewritten with real repo boundaries - TD-WP-0002: vertical spike reordering M0-M10 into one end-to-end thread that can falsify the crystallization thesis early - commit previously untracked INTENT.md and docs/ Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 1629012@bnt-lap001 Assistant-Session: 78d4fb13-8a1e-474b-87a3-9b9261c49a39
103 lines
3.9 KiB
Markdown
103 lines
3.9 KiB
Markdown
# SCOPE
|
||
|
||
> This file helps you quickly understand what this repository is about,
|
||
> when it is relevant, and when it is not.
|
||
|
||
---
|
||
|
||
## One-liner
|
||
|
||
`test-driver` is a use-case-driven verification framework whose tests mature
|
||
alongside the software they protect — fluid and agentic while behaviour is hot,
|
||
deterministic once it cools.
|
||
|
||
---
|
||
|
||
## Core Idea
|
||
|
||
A test is treated not as code but as a **verification asset** with identity,
|
||
intent, evidence, lineage, maturity, temperature and energy. Use cases are the
|
||
primary behavioural source; integration, journey, multi-user, security and
|
||
resilience tests are projections of the same use case rather than separate
|
||
suites.
|
||
|
||
Verification assets progress along a maturity continuum
|
||
(`T0 Exploratory → T5 Deterministic`) called **Crystallization**. Agents may
|
||
explore and realise semantic actions against unstable interfaces; oracles remain
|
||
deterministic and independent from actors, so the framework can distinguish a
|
||
legitimate mechanical change from a product defect rather than adapting to
|
||
whatever the implementation happens to do.
|
||
|
||
**Current state:** research prototype. Concept corpus is complete
|
||
(`INTENT.md`, `docs/`); implementation has not started. See
|
||
`history/2026-08-22-concept-assessment-swot.md` for the standing assessment and
|
||
the reasoning behind the current workplan sequence.
|
||
|
||
---
|
||
|
||
## In Scope
|
||
|
||
- The conceptual model: UseCase, Actor, Scenario, SemanticAction, Observation,
|
||
Oracle, Verdict, VerificationAsset, Finding, Adaptation, Crystallization.
|
||
- A deterministic semantic scenario kernel and its evidence format.
|
||
- The **test-driver lab** — a small mutable application under test carrying
|
||
labelled mechanical, semantic and defect mutations as ground truth.
|
||
- Adaptation detection and the defect-vs-adaptation classifier.
|
||
- Crystallization of agentic realisations into deterministic regression tests.
|
||
- Security testing expressed as mutation of ordinary use cases.
|
||
- Self-verification of the framework's own foundational guarantees.
|
||
- The research control plane: hypotheses, experiments, findings, fitness map.
|
||
|
||
---
|
||
|
||
## Out of Scope
|
||
|
||
- Replacing unit-test frameworks, browser automation engines, or CI systems.
|
||
- Building a load-testing, fuzzing, vulnerability-scanning or observability
|
||
platform.
|
||
- Test-management SaaS, distributed test clouds, or multi-tenant hosting.
|
||
- Making all tests agentic, or using model judgment where a deterministic oracle
|
||
is available.
|
||
- Rewriting semantic requirements to match implementation behaviour.
|
||
- Scale and performance verification before the conceptual model is proven.
|
||
|
||
---
|
||
|
||
## Relevant When
|
||
|
||
- You need the test-driver conceptual vocabulary or its canonical concept set.
|
||
- You are working on the crystallization, adaptation-classification, or
|
||
semantic-action binding mechanisms.
|
||
- You are extending the lab or its mutation catalogue.
|
||
- You need the framework's hypotheses, fitness scorecard, or evidence format.
|
||
|
||
---
|
||
|
||
## Not Relevant When
|
||
|
||
- You need ordinary unit or component tests for another repo — use that repo's
|
||
own test stack.
|
||
- You are looking for fleet coordination or cross-repo memory — that is State
|
||
Hub.
|
||
|
||
---
|
||
|
||
## Getting Oriented
|
||
|
||
1. `INTENT.md` — purpose, thesis, design heuristics, non-goals.
|
||
2. `docs/TestDriverConceptModel.md` — the canonical concept set v0.1.
|
||
3. `docs/TestDriverImprovementLoop.md` — hypotheses, findings taxonomy,
|
||
self-improvement cycle.
|
||
4. `docs/TestDriverInitialMilestones.md` — M0–M10 and the prototype success gate.
|
||
5. `history/2026-08-22-concept-assessment-swot.md` — assessment and the reasons
|
||
the first workplan reorders those milestones into a vertical spike.
|
||
6. `workplans/` — current work. Agent instructions: `AGENTS.md`.
|
||
|
||
---
|
||
|
||
## Stack
|
||
|
||
Deliberately boring, per `docs/TestDriverResearchPrototype.md`: Python, pytest,
|
||
Playwright, Pydantic/dataclasses, YAML, SQLite. One process, one database, one
|
||
browser engine, one application under test. Novelty belongs in the verification
|
||
model, not the infrastructure.
|