Support metadata-resolved app/package running conditions #12

New issue

Open

opened 2026-06-17 15:11:21 +02:00 by yorunikakeru · 0 comments

yorunikakeru commented

2026-06-17 15:11:21 +02:00

Owner

Goal

Planner should evaluate application/package liveness conditions from runtime snapshots without forcing users or DSL authors to know raw process-table invariants.

The user-facing intent is closer to:

app/package "steam" is running

not:

/proc/*/comm contains exactly "steam"

Required actions

Track the IR contract change that introduces an app/package process reference or equivalent condition.
Decide Planner snapshot shape for the resolved observation result:
- either keep SystemState as final booleans/resolved active app identities;
- or expand process state with structured metadata-backed match results.
Avoid duplicating package metadata resolution in Planner. Resolution belongs to Toad/runtime/metadata; Planner should remain pure snapshot evaluation.
Preserve deterministic evaluation for profile conditions.
Add JSON round-trip and golden tests for any SystemState contract change.
Add behavior tests proving app/package running conditions activate profiles from resolved runtime state.
Add CHANGELOG.md entry for any public JSON/SystemState/Planner contract changes.

Current context

Current Planner evaluates ProcessRunning name _observeStrategy by checking whether processNameText name is present in SystemState.runningProcesses. That is intentionally simple but too low-level for user-facing app identity.

The immediate local cleanup renamed the ignored field from _arguments to _observeStrategy; argv matching is not currently present in IR.

Dependencies

DSL issue: expose a user-facing appRunning/packageRunning constructor.
Toad issue: resolve app/package metadata to concrete process matchers and publish the result in snapshots.
IR contract update must land before Planner can consume new constructors or fields.

Acceptance criteria

Planner does not resolve package metadata itself.
Planner can evaluate the new app/package running condition from SystemState snapshots.
Existing raw process-name behavior is either kept as an explicit low-level contract or migrated with compatibility rules.
Tests cover true and false app/package running conditions and serialization compatibility.

## Goal Planner should evaluate application/package liveness conditions from runtime snapshots without forcing users or DSL authors to know raw process-table invariants. The user-facing intent is closer to: ```text app/package "steam" is running ``` not: ```text /proc/*/comm contains exactly "steam" ``` ## Required actions - Track the IR contract change that introduces an app/package process reference or equivalent condition. - Decide Planner snapshot shape for the resolved observation result: - either keep `SystemState` as final booleans/resolved active app identities; - or expand process state with structured metadata-backed match results. - Avoid duplicating package metadata resolution in Planner. Resolution belongs to Toad/runtime/metadata; Planner should remain pure snapshot evaluation. - Preserve deterministic evaluation for profile conditions. - Add JSON round-trip and golden tests for any `SystemState` contract change. - Add behavior tests proving app/package running conditions activate profiles from resolved runtime state. - Add `CHANGELOG.md` entry for any public JSON/SystemState/Planner contract changes. ## Current context Current Planner evaluates `ProcessRunning name _observeStrategy` by checking whether `processNameText name` is present in `SystemState.runningProcesses`. That is intentionally simple but too low-level for user-facing app identity. The immediate local cleanup renamed the ignored field from `_arguments` to `_observeStrategy`; argv matching is not currently present in IR. ## Dependencies - DSL issue: expose a user-facing `appRunning`/`packageRunning` constructor. - Toad issue: resolve app/package metadata to concrete process matchers and publish the result in snapshots. - IR contract update must land before Planner can consume new constructors or fields. ## Acceptance criteria - Planner does not resolve package metadata itself. - Planner can evaluate the new app/package running condition from `SystemState` snapshots. - Existing raw process-name behavior is either kept as an explicit low-level contract or migrated with compatibility rules. - Tests cover true and false app/package running conditions and serialization compatibility.