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

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions