Home

forge-test is the only repo in the Forge project that contains no part of the product. It holds a library of manual acceptance cases describing how a manufacturing ERP ought to behave across the whole life of a business — from a database with nothing in it, through bootstrap, master data, first transactions, first production cycle, and the exception cycles that follow — plus test-bed/, a browser-based runner that compiles those cases and walks a person through them.

The cases are written against industry-standard behaviour, not against Forge's screens. That single decision is what makes this repo useful to somebody who has not adopted Forge yet: the library is a specification you can read as "here is what this product believes an ERP owes you", and then run as a checklist against your own install. If a case describes something Forge cannot do, the case stays and the application gets a bug. Nothing here is automated — a person reads a case, performs the steps against a running system, and records what happened.

If you are evaluating Forge

Reading the library costs nothing and needs no install. Start with docs/: the schema, the glossary of manufacturing terms written for someone who has never worked in a shop, the per-phase case files and their manifests, and the cross-cutting suites. Every case says in plain English what a role is trying to accomplish, what they do, and what they should see. That is a more honest read of a product's ambitions than any feature list.

When you want evidence rather than ambition, stand up an install — the hub's Try Forge First lays out the options from a no-server demo SPA up to a seeded stack — and then work the Phase 0–5 sequence against it with the runner recording results. Running the Suite covers how.

Two things to be clear about before you start. The library is the standard, not the result — this repo does not publish which cases Forge currently passes, and reading it tells you nothing about whether it does. And the case library is deliberately broader than Forge: the suites include a full general-ledger family gated behind an optional module that no application implements yet, and the cases for it exist so the day something does implement it, the test already exists. See The Case Format for how that gating works.

What is in the repo

Path	What it holds
docs/01-schema.md	The case schema — the source of truth for what a case may contain
docs/test-scenarios.md	Library reference: philosophy, conventions, authoring guide
docs/runner-platform.md	Runner specification: architecture, data model, UX flows
docs/0*-phase-*.md, docs/1*-phase-*.md	The canonical lifecycle: a content file and a manifest per phase, P0 through P5
docs/cases/	Additional per-phase cases, one topic per file
docs/suites/	Cross-cutting suites, each with its own manifest
docs/flows.md, docs/stories.md	Business journeys as tags, and as ordered role-handoff narratives
docs/glossary.md	Manufacturing and ERP terms, defined for a non-specialist tester
test-bed/	The Angular runner and the content compiler that feeds it

The cross-cutting suites are accounting, audit, bulk-ops, concurrency, documents, edge-cases, integrations, list-views, notifications, permissions and reports. They are not a phase — they run against the state the phases leave behind, and most of their cases are independent of each other.

The phases run in sequence and each assumes the one before it: P0 bootstrap, P1 foundational records, P2 master data, P3 first transactions, P4 the first end-to-end production cycle, P5 the first exception cycles — damage, preventive maintenance, quality failure, subcontract, returns, period close.

What this repo deliberately does not do

The runner never calls Forge. It has no API client, no credentials, no knowledge of the application under test; it renders cases and stores what the tester says happened. That constraint is what lets the same library be pointed at any ERP, and it is why the runner can be a static page with no backend.

The library also stays out of several lanes on purpose: no code-level test scripts, no performance or load testing, no security testing, no UI selectors or locators, and no severity ratings on cases (severity belongs to a bug, not to a case). Automated tests live in the repos that own the code — see below.

Where to go next

Inside this wiki: The Case Format for how a case is written and read, and Running the Suite for pointing it at an install.

Up to the hub for anything product-level — the concepts the cases assume but do not define:

• Try Forge First — the evaluation surfaces, cheapest first
• Capability Gating — why a case can be inapplicable to a given install
• Accounting Modes — the branch that the accounting suite and the P0 integration cases fork on
• Access and Roles — what the permissions suite is asserting against
• Limits and Non-Goals — read this alongside any case that fails

Sideways, to the repos that own the automated suites: forge-ui (Playwright scenarios and Vitest units against the SPA) and forge-api (xUnit, including the architecture and capability-gate tests). forge-deploy builds and hosts this repo's runner as a service under its test profile.

Reporting what you find

A bug in the application goes to the Forge repo. A bug in a case, the schema, or the runner goes to this repo. The rule when a case fails is to stop at the first non-cosmetic failure and report it rather than working around it — the point of the case is that the described workflow should simply work.