stacklok / stacklok/modelith

Schema: action parameters and results

Open
#13 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Go
Stars
32
Forks
5
PR merge metrics
No merged PRs in 30d

Description

The gap

An action is {name, actor, preserves, description}. There is no way to declare what an action takes or what it reports back, so any contract about an action's output lives in freeform description text.

Motivating example, from modeling a diagram tool. Three separate decisions in one modeling session turned out to be about action results, and none of them was declarable:

  • Deleting a container recurses, and the result lists every node removed.
  • Deleting a shape converts bound arrow endpoints to free points, and the result warns about each conversion.
  • Dropping a stored overlap expectation as a side effect of a delete is reported in the result.

Each is a "no surprises" contract: the caller learns everything the operation did. Today each is a sentence inside an invariant or a description, for example:

- id: container-delete-recurses
  statement: >-
    Deleting a `Container` deletes its whole subtree. The
    operation's result lists every node removed.

The rule (preserves can point at it) and the report shape (nothing can) are fused into one prose statement.

Possible shape

Optional inputs and reports lists on the structured action form, each entry a name plus a type (primitive, enum, or entity name). This is deliberately short of a full signature language; the value is that the report contract becomes a checkable, renderable part of the model rather than prose. Lint could warn when a reports entry names an unknown entity, matching existing reference checks.

This may be over the line of what a plain-language modeling tool wants to carry; filing it as a data point from real usage rather than a firm request.

Workaround today

Prose in invariant statements and action descriptions.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the existing structured action schema and reference-checking or lint paths; the issue names no files or tests. Compare how action fields are modeled and rendered, then clarify whether inputs and reports belong in scope, including unknown-entity validation. Done means the agreed contract is represented and checked without relying on prose.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.