Skip to content

v0.0.4: enabled-events + per-state meta (agent brief) #48

Description

@fruwe

Coordination/tracking issue (not implemented directly — each linked issue is its own one-issue → one-PR work item).

Bring harel to v0.0.4: two small, engine-native primitives motivated by the "legal events from the current state" use case (SPEC §11; cf. statewright.ai agent guardrails).

Work items — in order (spec → conformance → impl)

A. Enabled events — the sorted declared events the active configuration handles (structural, guard-agnostic; leaf-up + across orthogonal regions; exclude reserved lifecycle events). Library + CLI harel enabled <inst> [--json] + in inspect; expect.enabled in the §9 test format.

B. Per-state meta: — an opaque meta: {…} map on a state (and the machine) the engine ignores; for host layers (guardrails/UIs). No effect on dispatch/validation/snapshots.

Rules

One issue → one PR · branch → PR → squash-merge → resolve threads · never push to main · no AI/assistant attribution anywhere. harel/harel-conformance merge on open; harel-python waits for CI (test (ubuntu-24.04) + conformance). Design decisions are settled in the issue bodies above — implement as written.

Verify (harel-python)

ruff check . · mypy src · pytest (unit) · pytest conformance (delete .cache/ to re-fetch). Bump src/harel/__about__.py0.0.4 in the impl PRs so conformance fetches main.

Release (maintainer, after all five merge)

Bump VERSION → 0.0.4 in harel + harel-conformance and tag v0.0.4 on both; leave harel-python untagged (tag triggers the gated PyPI publish, #14). harel-rust picks up v0.0.4 after v0.0.3.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions