@aopslabs/aops 0.3.31 → 0.3.33

package/agent-assets-release/agent-assets/core/bc42dd7792dbe66040e99a7ef3d80b3bc788c72b369b5a065cf936aef29f53fb/files/references/view/SKILL.md

@@ -1,58 +0,0 @@
----
-name: aops-cli-view
-description: Use for read-only local-cache dashboards, board/task/sprint details, filtered lists, hosted inventory, and focused context digests through aops view.
----
-
-# AOPS view
-
-`aops view` reads local presentation caches and never mutates or synchronizes
-them. Use it for orientation and bounded context; use owner commands (`pm`,
-`mem`, `doc`, and others) for hosted writes.
-
-## Fast paths
-
-```bash
-aops view dashboard --style agent
-aops view boards
-aops view tasks --board <slug> --status Doing
-aops view sprints --board <slug> --status doing
-aops view issues --status open --severity high
-aops view feedback --status open
-```
-
-Focused inspection accepts a full UUID, an unambiguous 8+ character ID prefix,
-a slug, or an exact title/name when supported:
-
-```bash
-aops view board <selector>
-aops view task <selector>
-aops view sprint <selector> --max-items 20
-aops view memory --subject sprint --id <sprint-id>
-aops view discussions --status open
-```
-
-## Context packs
-
-```bash
-aops view digest --task <task-id> --depth shallow
-aops view digest --sprint <sprint-id> --depth deep --max-bytes 32768
-aops view digest --board <board-slug> --depth deep
-```
-
-Use shallow first; request deep only when linked memory/discussions/details are
-actually needed. Markdown is the human/agent default; add `--json` for stable
-automation.
-
-## Hosted inventory
-
-```bash
-aops view hosted-projects --style compact
-aops view hosted-inventory --hosted-project <slug> --scope-resolution explicit
-```
-
-These are still read-only views. If output is stale, inspect `aops sync status
---json` and refresh intentionally with `aops sync pull --apply --json`.
-
-For exact filters and output limits, run the relevant nested `--help`. Do not
-edit generated view files, treat a view as canonical hosted state, or dump a
-deep digest when a small selector read is enough.

package/agent-assets-release/agent-assets/core/bc42dd7792dbe66040e99a7ef3d80b3bc788c72b369b5a065cf936aef29f53fb/files/references/working-disciplines/SKILL.md

@@ -1,66 +0,0 @@
----
-name: aops-working-disciplines
-description: Use only when the operator asks to choose, compare, or apply an AOPS working discipline such as solo, review-oriented, consensus-first, or coordinator-led work.
----
-
-# AOPS working disciplines
-
-Disciplines are optional working methods. Setup installs this reference so an
-agent can explain the choices, but neither setup nor gateway loading selects
-one. Read the relevant discipline only—not the whole guide—in
-`../../user-guides/working-disciplines.md`.
-
-Transport and method are separate:
-
-- mode: `solo`, `solo+async-review`, or `chat-room`;
-- discipline: the working method below.
-
-## Choose the smallest method
-
-| Discipline | Use when | Core evidence |
-| --- | --- | --- |
-| `solo-pm-loop` | One agent can deliver the bounded work | PM status, focused validation, handoff |
-| `build-review-chat` | Implementation benefits from an independent review | PM review-request/result; chat only wakes |
-| `design-first-consensus` | A material design decision needs independent stances before build | Discuss conclusion linked to plan |
-| `coordinator-loop` | Several delegated slices need explicit coordinator ownership | Projectman policy, slice tasks/reviews, integration gate |
-
-Do not choose a heavier discipline solely because multiple tools exist. The
-operator owns agent count, identities, roles, and closeout authority.
-
-## Compose startup
-
-```bash
-aops start --help
-aops start --task "<task>" --mode solo \
-  --discipline solo-pm-loop --json --out ./aops-start.md
-aops start --task "<task>" --mode chat-room \
-  --discipline build-review-chat --json --out ./aops-start.md
-```
-
-
-```bash
-  --policy-json '@policy.json' --apply --json
-```
-
-## Shared guardrails
-
-1. Put every implementation slice in Projectman before or at kickoff.
-2. Read live help/schema instead of guessing flags or payloads.
-3. Validate in proportion to risk and record only evidence actually produced.
-4. Use ChatV3 (`aops chat`) for coordination/wake, Discuss for consensus, and
-   Projectman review-request/result for review truth.
-5. Keep scope changes and blockers explicit; do not fabricate peer approval.
-6. Ordinary stop writes status/handoff and keeps board/room open.
-
-## Discipline-specific minimums
-
-- `solo-pm-loop`: orient → plan bounded slice → implement → validate → handoff.
-- `build-review-chat`: implementer validates → creates PM review request →
-  reviewer records result → material findings become issues/fix slices.
-- `design-first-consensus`: independent research/turns → every participant
-  records final stance → conclude → bind decision to implementation plan.
-- `coordinator-loop`: coordinator assigns non-overlapping slices → each owner
-  reports validation → independent review/integration gate → operator closeout.
-
-Use `aops start --reminder --task "<task>" --area <area> --json` for a bounded
-mid-session refresh instead of reloading the full discipline guide.

package/agent-assets-release/agent-assets/core/bc42dd7792dbe66040e99a7ef3d80b3bc788c72b369b5a065cf936aef29f53fb/files/user-guides/agent-assets.md

@@ -1,81 +0,0 @@
-# AOPS Community client assets
-
-Community client assets are installed from an independently signed
-agent-assets bundle included in the npm CLI. This asset identity is separate
-from application-image releases. The logical user-local data root is
-`~/.aops/agent-assets`.
-Every agent runtime registered by the installed CLI receives one managed
-`skills/aops/SKILL.md` gateway. Today this includes Codex and Claude; future
-runtimes can join the same registry without changing the asset model. The
-gateway resolves the immutable core package rather than copying every AOPS
-reference into each runtime.
-
-## Install and verify
-
-Use guided setup when configuring a new machine or server target:
-
-```text
-aops setup init
-```
-
-Use the normal explicit lifecycle from the installed npm package:
-
-```text
-aops assets install --target all --apply --json
-aops assets status --verify quick --json
-```
-
-Install verifies signed expected digests, refuses unowned runtime files, and
-does not use a repository as the source of core bytes. `status` is read-only;
-`--verify full` additionally rehashes every active, previous, and pinned
-immutable package file.
-
-`--target all` expands to every runtime registered by this CLI. A single
-runtime, comma-separated subset, or repeated `--target` is also accepted;
-`both` is not a selector. `--from-release` is only a maintainer/offline recovery
-override—the normal npm package resolves its verified bundled asset release.
-
-## Discover only what is needed
-
-```text
-aops assets resolve --gateway aops --json
-aops assets discover --query "<intent or domain>" --limit 5 --json
-aops assets resolve --name <exact-name> --json
-```
-
-Discovery returns bounded metadata candidates before any body is loaded.
-Resolve only the selected exact asset. The verified offline core includes a
-small neutral router, mounted-domain references, on-demand user guides, and the
-current working-discipline references. Setup makes those choices available;
-it does not silently select a board model, communication mode, or discipline.
-Optional hosted catalog packages also remain inert until explicitly selected.
-
-The core deliberately excludes private development architecture, machine
-paths, repository caches, and domains not mounted by Community. Exact live
-capability discovery remains the authority when a server adds custom domains.
-
-## Local and remote ownership
-
-The AOPS server may run locally or on another machine. Hosted records and
-optional packages remain server-owned; the verified client store, activation
-receipts, and runtime gateway stay on the user's machine. Repository caches do
-not replace or shadow the installed core.
-
-Fresh server setup may import an inert signed official catalog for optional
-discovery. `aops setup init --no-catalog` skips that initial import only; it
-does not remove existing rows or change the offline core.
-
-## Diagnose before repair
-
-```text
-aops assets status --verify quick --json
-aops assets repair --json
-aops assets migrate inspect --json
-```
-
-Mutations preview by default and require `--apply`. Destructive cleanup or an
-ownership transition additionally requires `--confirm`. Unknown or user-owned
-runtime files are reported and left untouched.
-
-Use `aops assets --help` and the selected subcommand's `--help` as the exact
-flag and safety contract for the installed CLI version.

package/agent-assets-release/agent-assets/core/bc42dd7792dbe66040e99a7ef3d80b3bc788c72b369b5a065cf936aef29f53fb/files/user-guides/agentspace.md

@@ -1,183 +0,0 @@
-<!-- Public packaged Agentspace guide. Current nested help and live schema win on drift. -->
-
-# Agentspace User Guide
-
-## 1 Ownership model
-
-Agentspace owns durable agent/operator context and reusable hosted assets:
-memory, synopsis, prompts, skills, resources, artifacts, activity, experience,
-agent profiles and structured discussion topics.
-
-It does not own every part of a work session:
-
-| Need | Canonical owner |
-| --- | --- |
-| task, sprint, issue, review request/result, handoff | Projectman |
-| versioned page/document content and retrieval | Docman |
-| encrypted coordination room, messages, cursors, foreground listen | ChatV3 via `aops chat` |
-| structured decision stances and conclusion | Agentspace Discuss via `aops discuss` |
-| repository files and commits | Git/source repository |
-
-The former Agentspace hosted-chat sugar and its `room/inbox/catchup` command
-shape are retired from `aops chat`. Existing server data may remain for
-historical readback, but new coordination uses ChatV3. `aops chatv3` is only a
-compatibility alias for `aops chat`.
-
-## 2 Startup and resume ladder
-
-Prefer small, token-efficient reads:
-
-```bash
-aops mem brief --subject project --json
-aops mem search --q "<decision or constraint>" --limit 10 --json
-aops view digest --task <task-id> --depth shallow
-aops pm review-request list --status open --json
-aops chat session list --json
-```
-
-Do not preload every memory, guide, room transcript, or PM record. Resolve
-references only when the current task needs them.
-
-## 3 Durable memory and synopsis
-
-Memory is for facts that must survive the current context: decisions,
-constraints, bounded handoffs, blockers, validation state, and the next safe
-action. It is not a duplicate task tracker and must not contain secrets, large
-logs, raw chat transcripts, or full documents.
-
-```bash
-aops mem list --durability sticky --json
-aops mem search --q "migration decision" --limit 10 --json
-aops mem write --mode decision --subject project \
-  --content "<bounded evidence and decision>" --apply --json
-aops mem checkpoint --help
-aops mem synopsis --subject project --json
-```
-
-A good checkpoint contains the request/purpose, PM and repository refs,
-concrete outcome, validation/review evidence, open risk, and next action.
-Write at meaningful milestones—not after every message or small edit.
-
-Generated synopsis is a read model over durable context. Rebuild/read it when
-resume quality is poor; do not treat it as an independent source of truth.
-
-## 4 Reusable hosted assets
-
-```bash
-aops prompt list --json
-aops skill list --json
-aops resource list --json
-aops artifact list --json
-aops exp list --json
-```
-
-Prompts and skills are versioned server records. Resources point to knowledge;
-artifacts describe or reference outputs and are not an unlimited binary store.
-Create/update/version/publish commands are guarded writes. Inspect help first,
-use idempotency for retries, and read back the exact version after mutation.
-
-```bash
-aops skill version create --help
-aops prompt version create --help
-aops resource create --help
-aops artifact create --help
-```
-
-Never put credentials, private keys, bearer/member tokens, or machine-local
-secret paths into hosted assets.
-
-## 5 Structured discussions
-
-Use `aops discuss` only when a material decision needs independent stances and
-a durable conclusion. Small reversible implementation choices do not need a
-discussion ritual.
-
-```bash
-aops discuss start --title "<decision>" --question "<question>" \
-  --participant <agent-a> --participant <agent-b> --apply --json
-aops discuss turn --topic <topic> --agent <agent> \
-  --kind statement --from-file ./turn.md --apply --json
-aops discuss wait --topic <topic> --agent <agent> \
-  --timeout-sec 540 --interval-sec 5 --json
-aops discuss turn --topic <topic> --agent <agent> \
-  --kind final-stance --from-file ./final.md --apply --json
-aops discuss conclude --topic <topic> --apply --json
-```
-
-Never invent another participant's stance. Conclude only after every required
-participant recorded a final stance and the status readback reports no missing
-finals. Link the conclusion into Projectman or memory.
-
-Discussion waits and ChatV3 listeners are separate mechanisms. A Discuss turn
-does not wake a ChatV3 listener automatically. Send a short `aops chat send`
-message with the topic/turn reference when a peer must act.
-
-## 6 ChatV3 coordination
-
-ChatV3 owns coordination and wake traffic:
-
-```bash
-aops chat join "<invite>" --handle <agent> --save-session --json
-aops chat binding add --session <session> --room general \
-  --binding-type projectman.review-request --ref-id <rr-id> --json
-aops chat send --session <session> --room general \
-  "REVIEW READY: <rr-id>" --json
-aops chat listen --session <session> --room general \
-  --after-seq <last-seq> --timeout-sec 60 --json
-aops chat read --session <session> --room general \
-  --after-seq <last-seq> --mark-delivered --mark-read --json
-```
-
-Keep foreground listening while room-owned work remains. Timeout exit `22`
-means only that the bounded interval was quiet. Read PM/RR/Docman/Discuss refs
-before acting, post a short ACK, and advance cursors only for messages actually
-consumed.
-
-Session credentials are isolated by local agent owner. Do not share a session
-id or store between agents. See the ChatV3 guide for migration and cursor-gap
-rules.
-
-## 7 Review pairing
-
-Projectman is the review truth:
-
-```bash
-aops pm review-request create --help
-aops pm review-request get --id <rr-id> --json
-aops pm review-request result --help
-```
-
-Use ChatV3 only to wake the reviewer and point to the canonical RR. Material
-review findings become Projectman issues. Re-review is a child RR, not an edit
-of the prior immutable result.
-
-For Docman drafts, include document/page identifiers plus the compose or
-materialize `contentHash` in the RR reference. The result must repeat the exact
-same evidence reference. If the draft hash changes, the old acceptance covers
-only the old bytes and a new re-review is required.
-
-
-## 9 Raw discovery and troubleshooting
-
-```bash
-aops agent tools --domain agentspace --summary --json
-aops agent schema --tool agentspace.<operation> --summary --json
-aops agent invoke --tool agentspace.<operation> \
-  --input '@payload.json' --preview --json
-```
-
-Use the detail ladder: this guide → nested help → live schema → guarded raw
-invoke. If the connected server advertises capabilities absent from this
-public core, trust the live catalog for availability but keep owner and secret
-boundaries intact.
-
-Common failures:
-
-- quiet listener: continue from the last acknowledged sequence; timeout is not
-  completion;
-- PM record changed but peer slept: send a ChatV3 wake with the PM ref;
-- send succeeded but cursor did not advance: read the reported unseen gap;
-- local session not found after upgrade: load the exact legacy session once so
-  it can be claimed by the current agent owner;
-- owner mismatch: use the correct agent session or explicit owner; never copy
-  another agent's credential store.