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 (100 characters); optional Markdown description (50,000 characters)
  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 mutations receiver-owned; callers observe Projects, Issues and Comments by reading the graph under their own authority:

Project.create
Project.update | addMember | removeMember | createIssue | receiveReport | createTag | archive
Issue.update | edit | 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 Action rejects them explicitly (TAG_TOO_LARGE_TO_DELETE) instead of submitting an oversized Mutation with a backend-dependent failure.

Project.create requires authentication. A Project's owner and members observe the Project, its Issues and their Comments through the graph, under their own authority. A reporter observes its own Issues the same way: from its Identity through issue_reported_by, then each Issue's Comments. Receiver Methods use Schema-owned Policies: Project owners administer metadata, membership, Tags, and archival; owners and members contribute to Issues; an Issue's reporter edits its title and description through Issue.edit and archives it; only a Comment author edits or deletes it. Priority, status, assignment, Tags, parent, and Comments remain collaborator operations. Issues and their Comments are visible through a Project the caller owns or has joined, and to the Issue's reporter. Deleting an Identity, such as by uninstalling the Domain that owns it, removes only its issue_reported_by, comment_authored_by and project_owned_by Edges: its Issues, Comments and Projects stay, with their reporterId, authorId and ownerId. A Project whose owner is deleted keeps its members, who still contribute, but no one administers it, and a Comment whose author is deleted can no longer be edited or deleted.

An Issue's title is its Kernel Named name, which holds 100 characters. Its description is the Issues-owned body, because Kernel Descriptable holds only 1,000 characters. An Issue described before body existed keeps that description in Descriptable until its next revision moves it to body; readers take body first, then the Descriptable description. Titles and descriptions are stored without surrounding whitespace. Every callable refuses a longer title or description before it runs, and refuses a blank title or a revision that names no field with a declared error.

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. Queries and Actions 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.

Project.receiveReport is the owner-only intake for trusted integrations such as Admin. Its owner supplies a verified reporterId, an opaque requestId, title, body, and optional structured context. The public Admin facade must derive the reporter from authentication; ordinary senders must not receive this privileged owner capability or Project membership.

One atomic mutation allocates the number, creates the Issue and reporter/containment edges, retains the original report exactly as received, and describes the Issue with its trimmed body. A Query v7 guard fences the exact Project/reporter/request triple. A retry with identical content returns the original { id, reference }, even after triage edits or archival; changed content under the same key is rejected. Independent request IDs remain independent reports. Known counter/key contention is retried up to eight attempts; unknown outcomes propagate, so the sender must retain the original payload and key until confirmation. Durability comes from the graph receipt and atomic preconditions.

Context describes current client observations, separate from mutable Issue text. Missing versions and instance coordinates remain unknown. Creating a report makes the sender the Issue's reporter, with the reporter access above; it grants no Project membership and no access to other Issues or Tags. The generic domain has no Admin dependency. Receiving a report performs no automatic triage, duplicate matching, or background processing.

Other creation methods retain their existing retry semantics. Set-style changes converge naturally; stale concurrent edits reject through atomic mutation preconditions.

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 filters the visible Issues on the server and reads them a page at a time. A search keeps the Issues read so far that mention it and says when more may match. 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.