PHPackages                             lemric/psr-wf - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [PSR & Standards](/categories/psr-standards)
4. /
5. lemric/psr-wf

ActiveLibrary[PSR & Standards](/categories/psr-standards)

lemric/psr-wf
=============

1.0.0(6mo ago)02GPL-3.0-or-laterPHPPHP ^8.2

Since Oct 12Pushed 6mo agoCompare

[ Source](https://github.com/Lemric/psr-wf)[ Packagist](https://packagist.org/packages/lemric/psr-wf)[ RSS](/packages/lemric-psr-wf/feed)WikiDiscussions master Synced 1mo ago

READMEChangelog (1)Dependencies (1)Versions (2)Used By (0)

PSR-WF: Workflow for PHP — Draft Specification v1.0.0
=====================================================

[](#psr-wf-workflow-for-php--draft-specification-v100)

> **Status:** Draft
> **Target PHP:** 8.4+
> **Dependencies:** PSR-3 (Logger), PSR-11 (Container), PSR-14 (Events), PSR-6/16 (Cache – optional)
> **Authors:** Lemric Group
> **Purpose:** Define interoperable contracts and execution semantics for a **finite state machine workflow** (single active state) with **conditions**, **validators**, **post-functions**, **triggers**, and **schemes**, portable across frameworks (Symfony/Laravel/custom).

---

1. Motivation & Goals
-------------------------

[](#1-motivation--goals)

Modern PHP applications often require configurable business processes: status transitions, gatekeeping rules, validations, and side-effects. Existing solutions are framework-specific and incompatible. **PSR‑WF** defines **standardized interfaces** and **semantics** to:

- express a **single-marking finite state machine** (FSM) for domain subjects;
- provide **extensible rule chains**: *Conditions*, *Validators*, *PostFunctions*, and *Triggers*;
- map workflow definitions to **contexts** via **schemes**;
- integrate with **PSR‑14** events, **PSR‑11** containers, and **PSR‑3** logging;
- remain agnostic of persistence, configuration format, and UI.

Non-goals: BPMN modeling, multi-marking/parallel tokens, job orchestration, storage and transport formats.

---

2. Terminology
--------------

[](#2-terminology)

- **Subject** – domain object governed by a workflow (e.g., Issue, Order).
- **Status** – single active state of a Subject (e.g., `open`, `in_progress`, `done`).
- **Transition** – directed edge `from[] -> to` guarded by rules and actions.
- **Condition** – decides if a Transition is visible/allowed for the Actor+Context.
- **Validator** – asserts runtime data correctness at execution time (may raise error).
- **PostFunction** – performs side-effects *after* a successful status change.
- **Trigger** – external or time-based cause that attempts a Transition.
- **Workflow** – named graph of Statuses and Transitions with an initial status.
- **Scheme** – resolver mapping Contexts (e.g., project/type) to Workflow keys.
- **Context** – metadata describing execution environment (project, tenant, locale).
- **Actor** – user/system identity attempting or executing a Transition.
- **Engine** – component evaluating rules and executing Transitions atomically.
- **MarkingStore** – reads/writes the Subject’s current Status.

---

3. Design Principles
--------------------

[](#3-design-principles)

- **Interoperability first** – portable contracts; no framework assumptions.
- **Determinism** – defined evaluation order and transaction semantics.
- **Extensibility** – Strategy + Chain-of-Responsibility for all rule types.
- **Separation of concerns** – definition vs. execution vs. persistence vs. UI.
- **Safety** – explicit error classes, auditability hooks, least privilege bias.
- **Performance** – caching encouraged; minimal allocations on hot paths.

---

4. Interfaces
-------------

[](#4-interfaces)

> All namespaces below are **`Psr\Workflow`**. Implementations **must** declare `declare(strict_types=1);` and type-hint accurately.

```