QEloop

KO | EN

gitlite — search

#pytorch #codex #gpt #editor #macos #kubernetes #react #ruby #openai #java

(★ 9)

Evidence-driven quality engineering loop.

File Explorer

ZIP Download

- - generic-release.yml
- qe-loop.mjs
- agent-workflows.example.yaml
- confluence.example.yaml
- demo-knowledge.example.yaml
- demo-target.example.yaml
- knowledge.yaml
- project-profile.example.yaml
- project-taxonomy.example.yaml
- target.example.yaml
- - dashboard.html
  - login.html
  - orders.html
  - styles.css
  - users.html
- server.mjs
- - 0001-semantic-graph-core.md
  - 0002-wiki-as-projection.md
  - 0003-verification-ledger.md
  - 0004-state-dimensions.md
- - qe-loop-lifecycle-verification-map.html
  - qe-loop-lifecycle-verification-map.png
- - CODEX_WORKFLOW.md
  - CODEX_WORKFLOW.zh-CN.md
  - DEMO_CLOSED_LOOP.md
  - DEMO_CLOSED_LOOP.zh-CN.md
  - QE_LOOP_ONBOARDING.md
  - QE_LOOP_ONBOARDING.zh-CN.md
- - generic-release-demo-report.html
- ADOPTION_HYPOTHESIS.md
- ADOPTION_HYPOTHESIS.zh-CN.md
- DEPENDENCY_PROFILES.md
- DEPENDENCY_PROFILES.zh-CN.md
- EXTERNAL_ACCEPTANCE.md
- EXTERNAL_ACCEPTANCE.zh-CN.md
- HUMAN_IN_THE_LOOP_QE_LIFECYCLE.zh-CN.md
- IDE_AGENT_BRIDGE.md
- IDE_AGENT_BRIDGE.zh-CN.md
- KNOWLEDGE_VAULT_GUIDE.md
- OPERATIONS.md
- PRODUCT_BOUNDARY.md
- PRODUCT_BOUNDARY.zh-CN.md
- PRODUCT_ROADMAP.zh-CN.md
- PROJECT_OVERVIEW.zh-CN.md
- PUBLIC_PRODUCT_STRUCTURE.md
- PUBLIC_PRODUCT_STRUCTURE.zh-CN.md
- QE_LOOP_DIAGRAMS.zh-CN.md
- QUICK_START.md
- QUICK_START.zh-CN.md
- README.zh-CN.md
- REAL_TARGET_SETUP.md
- REAL_TARGET_SETUP.zh-CN.md
- RELEASE_CHECKLIST.md
- RELEASE_CHECKLIST.zh-CN.md
- RELEASE_NOTES.md
- RELEASE_POSITIONING.md
- SAMPLE_REPORT.md
- SAMPLE_REPORT.zh-CN.md
- SECURITY_BOUNDARY.md
- SECURITY_BOUNDARY.zh-CN.md
- SEMANTIC_CORE_IMPROVEMENT_PLAN.zh-CN.md
- TASK_GOVERNANCE.md
- TASK_GOVERNANCE.zh-CN.md
- USER_GUIDE.md
- - agent_contract.schema.yaml
  - api_endpoint.schema.yaml
  - automation_suite.schema.yaml
  - flow.schema.yaml
  - skill.schema.yaml
  - test_case.schema.yaml
  - ui_menu.schema.yaml
- - test_case_charter.md
  - test_case_e2e_steps.md
- AGENTS.md
- README.md
- build-release-dist.mjs
- render-core-doc-mermaid-png.mjs
- run-demo-closed-loop.mjs
- seed-demo-data.ts
- sync-generic-release-repo.ts
- verify-generic-release-demo.ts
- - README.md
- - config-domain.ts
  - index.ts
- - api-analyzer.ts
  - api-evidence-catalog.ts
  - declared-actions-analyzer.ts
  - flow-analyzer.ts
  - inference-merger.ts
  - js-static-analyzer.ts
  - llm-client.ts
  - page-analyzer.ts
  - test-blueprint-generator.ts
- - api-auth-health.ts
- - args.ts
  - command-registry.ts
  - command-types.ts
  - help.ts
  - index.ts
  - repair-menu-paths.ts
- - README.md
- - contracts.ts
  - execution-namespace.ts
- - action-explorer.ts
  - browser.ts
  - crawl-targets.ts
  - element-extractor.ts
  - list-query-probe.ts
  - login.ts
  - menu-discovery.ts
  - network-recorder.ts
  - page-capture.ts
  - pagination-probe.ts
  - tab-discovery.ts
  - write-action-discovery.ts
- - write-inference.ts
- - index.ts
- - api-spec-generator.ts
  - api-test-blueprint-generator.ts
  - fixture-generator.ts
  - import-paths.ts
  - page-object-generator.ts
  - playwright-spec-generator.ts
  - test-generator.ts
- - index.ts
- - canvas-writer.ts
  - flow-diagram.ts
  - markdown-templates.ts
  - vault-writer.ts
- - project-audit.ts
  - project-export.ts
  - project-profile.ts
- - chrome-evidence-ingest.ts
  - jira-issue-crawl.ts
  - requirement-impact-analysis.ts
  - requirement-test-assets.ts
  - requirement-tree-ingest.ts
  - requirement-url-ingest.ts
  - requirement-verification-loop.ts
  - source-ingest-plan.ts
  - zentao-case-crawl.ts
- - index.ts
- - index.ts
- - api-failure-classifier.ts
  - failure-knowledge-context.ts
  - regression-runner.ts
  - report-collector.ts
  - run-identity.ts
- - api-execution-gate.ts
  - owned-test-data.ts
- - knowledge-paths.ts
  - normalize-api-catalog.ts
- - diff.ts
  - exporter.ts
  - file-store.ts
  - llm-schemas.ts
  - persist.ts
  - schema.ts
  - sqlite-store.ts
  - storage-adapter.ts
  - storage-mode.ts
- - auth-adapters.ts
  - target-registry.ts
- - api-auth-profile.ts
  - api-sample-pick.ts
  - apply-menu-paths.ts
  - config.ts
  - data-paths.ts
  - dotenv.ts
  - hashing.ts
  - http-client.ts
  - logger.ts
  - login-url.ts
  - menu-path.ts
  - menu-tree-lookup.ts
  - platform.ts
  - process-lock.ts
  - route-limit.ts
  - safe-fs.ts
  - sanitize.ts
  - selectors.ts
- - verification-ledger.ts
- - kb-ask-page.ts
  - README.md
  - server.ts
- - qe-loop-test.ts
  - test-data.ts
- - api-assert.ts
  - api-request.ts
- - generated-pages.ts
- - compiled-cli-smoke.test.ts
  - config-yaml-parser.test.ts
  - high-risk-behavior.test.ts
  - playwright-ffmpeg-detection.test.ts
  - public-domain-boundary.test.ts
  - public-release-boundary.test.ts
- global-setup.ts
.dockerignore
.gitignore
.npmignore
DEPLOYMENT.md
docker-compose.yml
Dockerfile
LICENSE
package-lock.json
package.json
playwright.config.ts
README.md
README.zh-CN.md
release-manifest.json
tsconfig.json

# Use via CDN

jsDelivr

jsDelivr serves any public GitHub repository as a CDN with zero setup. Pick a version and a file to get a ready-to-paste link and snippet.

Version

File

Link

Example

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

中文版本: [`README.zh-CN.md`](README.zh-CN.md)

Local-first, evidence-driven quality engineering loop for configurable web systems.

```text
capture -> analyze -> evidence/knowledge vault -> requirement impact -> test generation
```

QE Loop collects page/API evidence, organizes it into a local knowledge vault, and supports requirement impact analysis, layered test generation, executable smoke seeds, and repeatable reports.

The default product path is intentionally simple: configure a Web target, capture evidence, analyze it, generate tests, run selected checks, and publish a repeatable report. Integrations for documents, issue systems, browser evidence, and knowledge exports can be enabled when they add useful evidence; they are not required for the demo loop.

## Value Hypothesis

QE Loop is not designed as "LLM writes tests from prompts." Its core assumption is that a quality team can build a durable semantic layer from evidence that already exists around a web system: pages, APIs, configuration, requirements, issues, generated tests, and execution reports.

This matters especially for small and mid-sized companies. They often cannot wait for a complete product taxonomy, a centralized data-modeling program, or a fully governed enterprise knowledge platform. A lower-cost path is to start from observable system evidence, normalize it into a local knowledge base, and let agents reason over that verified context.

The framework is shaped by five adoption assumptions:

- Semantic modeling starts from evidence, not meetings. Page captures, API samples, route trees, configs, requirements, and reports become the raw material for business concepts, flows, risks, and test scope.
- A test team can become agent-operated. Humans define strategy, risk boundaries, data safety rules, and release gates; agents handle repetitive capture, diffing, impact analysis, test generation, execution, and report refresh.
- One strong owner can coordinate many repeatable workers. A single test leader should be able to define objectives and gates once, then let agents fan out across modules, environments, evidence sources, and report formats.
- The framework should live close to development tools. CLI commands, config files, manifests, generated specs, and reports are intentionally file-first so they can be surfaced later inside IDE workflows such as change impact, evidence lookup, and test generation from the developer's current context.
- QA can reverse-map the company business model. Instead of waiting for product or data teams to complete a top-down model, QA can reconstruct an executable bottom-up model from how the system actually behaves, while still keeping product and data owners as reviewers of business meaning.

That is why QE Loop uses an evidence-chain mode: every AI-generated summary, requirement impact result, test asset, and report should be traceable back to captured or imported evidence. The goal is not to replace human judgment; it is to make human judgment compound through reusable, verifiable system knowledge.

For the full adoption model, see `docs/ADOPTION_HYPOTHESIS.md`.

## Requirements

- Node.js >= 20.0.0
- Google Chrome for Playwright `channel: "chrome"` flows
- Optional OpenAI-compatible LLM env vars: `LLM_API_KEY`, `LLM_BASE_URL`

The generic example uses `storage.mode=json-file` and does not require SQLite. Advanced configurations can opt into `sqlite` or `hybrid` storage; those modes require Node.js >= 22.5.0 because they use `node:sqlite`.

## Quick Start

```bash
npm install
npm run build
npm run help
npm run demo:run
```

Real target path:

```bash
cp config/target.example.yaml config/target.yaml
npm run cli -- doctor --config config/target.yaml
npm run cli -- capture --config config/target.yaml
npm run cli -- analyze --config config/target.yaml
npm run cli -- generate --config config/target.yaml
npm run cli -- run --config config/target.yaml
npm run cli -- report --config config/target.yaml
```

Published generic CLI usage prefers `npx qe-loop ...`. Source checkout usage can use `npm run cli -- ...`.

For advanced commands and optional connectors:

```bash
npm run help:all
```

The first screen only shows the public Web QE loop.

## Product Model

QE Loop separates the evidence loop, optional evidence sources, and local runtime artifacts:

| Layer | Purpose |
| --- | --- |
| Core Loop | Target config, capture, analysis, knowledge map, impact, generation, run/report |
| Evidence Sources | Optional document systems, issue systems, browser evidence import, and knowledge export adapters |
| Local Runtime | Local-only Web UI, filesystem artifacts, demo app, generated tests, and reports |
| Extensions | Explicit adapters or connector packages for team-specific tools and workflows |

For capability scope and extension points, see `docs/PRODUCT_BOUNDARY.md`.

## Documentation

| Document | Purpose |
| --- | --- |
| `README.zh-CN.md` | Chinese overview for the framework, release boundary, demo verification, and command groups |
| `docs/PROJECT_OVERVIEW.zh-CN.md` | Canonical Chinese project overview for evidence, Semantic Core, verification, human-in-the-loop, and product boundaries |
| `docs/README.zh-CN.md` | Categorized Chinese documentation index |
| `docs/ADOPTION_HYPOTHESIS.md` | Adoption hypothesis for semantic modeling, agent-operated QA, IDE integration, and bottom-up business modeling |
| `docs/PRODUCT_BOUNDARY.md` | Capability scope, default loop, optional evidence sources, and extension points |
| `docs/QUICK_START.md` | 5-minute demo path for a clean QE Loop run |
| `docs/REAL_TARGET_SETUP.md` | Minimum real-target setup: target config, auth, crawl, analyze, generate, run |
| `docs/PRODUCT_ROADMAP.zh-CN.md` | Product roadmap from narrow Core to extensions, change-aware QE, IDE clients, and server |
| `docs/SEMANTIC_CORE_IMPROVEMENT_PLAN.zh-CN.md` | Detailed Semantic Core and verification-ledger implementation plan |
| `docs/HUMAN_IN_THE_LOOP_QE_LIFECYCLE.zh-CN.md` | Human-in-the-loop lifecycle from requirement intake to production verification and knowledge refresh |
| `docs/QE_LOOP_DIAGRAMS.zh-CN.md` | PNG atlas for the core architecture, lifecycle, state, and roadmap diagrams |

See `docs/README.zh-CN.md` for the full bilingual documentation map.

## CLI Structure

Default help shows the public Web QE loop only. Optional connectors and compatibility commands are shown with `help --all`.

Core command groups:

- `init`, `doctor`, `capture`, `analyze`, `generate`, `run`, `report`
- `auth`, `auth:check`, `crawl`, `api:evidence`
- `kb:*` knowledge commands and optional exports
- `requirement:*` impact/test generation commands
- `confluence:*`, `jira:crawl`, `zentao:*` optional source import commands
- compatibility commands: `generate:vault`, `generate:tests`, `test`

## Storage

Supported storage modes:

| Mode | Behavior |
| --- | --- |
| `json-file` | File-first evidence storage; does not open SQLite |
| `sqlite` | SQLite-only compatibility storage |
| `hybrid` | SQLite + JSON export for compatibility workflows |

The persistence entry point is `src/storage/storage-adapter.ts`.

## Demo

To verify the generic QE Loop release package end to end:

```bash
npm run release:generic:verify-demo
```

This runs audit, export, pack, clean install, demo server, demo run, and report generation. The release verification summary is written to `data/reports/release-generic/latest.json` and `data/reports/release-generic/latest.md`.

For local demo debugging:

```bash
npm run demo:server
npm run demo:run
```

`demo:run` prepares demo data, knowledge output, generated tests, API smoke tests, UI smoke tests, and reports.
Demo-owned evidence, knowledge output, and generated specs are written under `data/demo/` through `config/demo-target.example.yaml` and `config/demo-knowledge.example.yaml`; the combined API/UI summary and per-layer Playwright JSON snapshots are written to `data/reports/latest/`.

## Verification

```bash
npm run typecheck
npm run test:unit
npm run kb:lint
npm run kb:unified-index
```

In restricted sandboxes, `npm run kb:*` may need to run outside the sandbox because `tsx` can create an IPC pipe.

## License

QEloop

File Explorer

# Use via CDN

Was this content helpful?

Recent Feedback

Download README