Issues Domain

issues.astrale.ai owns collaborative Projects, numbered Issues, Comments, and Project-local Tags. It is an Astrale Application with Schema Policies, receiver Methods, atomic Mutations, and an inbox-first Shell View.

The graph Schema depends only on Kernel: collaboration edges target any Identity subtype. Shell is a frontend integration, not a pinned Schema dependency or a source of Core group data.

Project
  owned by one Identity; shared with member Identities
  key, name, optional description, private owner/member execution index and nextIssueNumber, archived
  contains Issues and Tags

Issue
  immutable reference; title; optional description
  status: open | accepted | resolved | deferred | closed
  priority: 0..4; optional assignee; optional acyclic parent; Tags

Comment
  body; immutable author; belongs to one Issue

Tag
  name; Project-local slug; optional color; belongs to one Project

The public callable surface keeps observation Project-owned and mutations receiver-owned:

Project.create
Project.list
Project.update | addMember | removeMember | createIssue | createTag | archive
Issue.update | transition | assign | setTags | setParent | addComment | archive
Comment.edit | delete
Tag.edit | delete

Tag.delete remains one atomic Mutation through 2,046 linked Issues, the current supported Kernel execution ceiling after its containment and Node removals. Larger Tags must first be removed from enough Issues through Issue.setTags; the Workflow rejects them explicitly instead of submitting an oversized Mutation with a backend-dependent failure.

Project.create and Project.list require authentication. Project.list returns only Projects the caller owns or has joined, with their visible Issues and Comment threads nested for one CLI/agent observation. Receiver Methods use Schema-owned Policies: Project owners administer metadata, membership, Tags, and archival; owners and members contribute to Issues; only a Comment author edits or deletes it. Reads are visible only through a Project the caller owns or has joined.

Ownership, membership, reporting, assignment, and authorship remain graph-native Policy facts. The owning Project, Issue, or Comment also stores the corresponding Identity IDs privately, updated in the same atomic Mutation as each edge. Recipes and Workflows can therefore validate current collaboration state without requesting authority over every possible concrete Identity subtype from another Domain. Those private execution fields are not a second public model and never replace the Policy edges.

There is no Domain Command, receipt, universal idempotency layer, activity log, or undo system. Project.create and Project.list are Actions; the seventeen multi-step receiver operations are explicit Workflows whose Query and Mutation effects use stable steps. Set-style changes converge naturally and stale concurrent writes reject through atomic Mutation preconditions. Creation retries have no Domain replay guarantee; generic invocation idempotency belongs to the platform when it exists.

The mounted View defaults to a focused open-Issue Inbox with queue progress and keyboard or button navigation. Accepted work has a dedicated discussion view, while Browse searches and filters the complete visible corpus with bounded pagination. The roomy metadata drawer exposes Close, Defer, Resolved, and Accept triage actions plus priority, assignment, Tags, and parent controls without blurring the main view. The four outcomes display and honor the C, D, R, and A keyboard shortcuts whenever the user is not typing. The selected Issue description and its Comment thread remain below the inbox as one continuous Markdown conversation with strict Mermaid diagrams. Project, Issue, and Tag creation and Project membership administration intentionally remain API-first.

Development

Dependency changes must refresh both issues/pnpm-lock.yaml and the workspace-root pnpm-lock.yaml; repository CI installs the latter with a frozen lockfile.

pnpm install
pnpm typecheck
pnpm test
pnpm lint
pnpm frontend:build
pnpm build
pnpm package

Domain source imports Kernel concepts through semantic @astrale-os/sdk/* facades and owns no .spec tree.