@aopslabs/aops 0.3.30 → 0.3.32

package/assets/agent-assets/core/references/chatv3/SKILL.md

@@ -1,59 +0,0 @@
----
-name: aops-cli-chat
-description: Use for ChatV3 encrypted channels, invitations, agent-owned local sessions, membership, presence, bindings, messages, cursors, and foreground listening through aops chat.
----
-
-# AOPS Chat (ChatV3)
-
-`aops chat` is the canonical encrypted ChatV3 channel/room surface for agent
-coordination and product-room work. `aops chatv3` is a compatibility alias for
-the same command tree; it is not a second messaging system.
-
-Read only the relevant section of `../../user-guides/chatv3.md`. Exact flags
-come from nested help; direct payloads come from live schema.
-
-## Common entry points
-
-```bash
-aops chat --help
-aops chat channel --help
-aops chat session --help
-aops chat member --help
-aops chat send --help
-aops chat read --help
-aops chat listen --help
-```
-
-Typical foreground coordination:
-
-```bash
-aops chat session list --json
-aops chat listen --session <id> --room general --after-seq <n> --timeout-sec 60 --json
-aops chat send --session <id> --room general "<message>" --json
-aops chat read --session <id> --room general --after-seq <n> --mark-delivered --mark-read --json
-```
-
-Keep foreground listening active while work remains. A listen timeout means
-only “no message in this bounded interval”; it does not end the task.
-
-Local sessions are isolated by detected agent owner (for example a Codex
-thread), or by `AOPS_CHATV3_SESSION_OWNER` / `--session-owner`. Session ids,
-member tokens, and room keys must never be copied between agent owners or
-pasted into chat, logs, source, or shell history. Legacy shared stores are
-claimed once and migrated into the first local owner that uses that session.
-
-`send --mark-read` and `send --mark-delivered` advance cursors only when the
-pre-send cursor is exactly caught up. If another message arrived first, the
-send succeeds but the cursor advance is skipped; read the gap explicitly.
-
-For a write not exposed by sugar, inspect the exact live schema first:
-
-```bash
-aops agent tools --domain chatv3 --summary --json
-aops agent schema --tool chatv3.<operation> --summary --json
-aops agent invoke --tool chatv3.<operation> --input '@payload.json' --preview --json
-```
-
-ChatV3 is coordination/wake truth, not the durable Projectman review record or
-the structured `discuss` transcript. Bind or summarize outcomes into the
-correct owner when durability matters.

package/assets/agent-assets/core/references/collaborative-work/SKILL.md

@@ -1,81 +0,0 @@
----
-name: aops-collaborative-work
-description: Use when the operator explicitly wants the full AOPS session playbook for solo work, async review, or ChatV3 room collaboration with Projectman-backed execution.
----
-
-# AOPS collaborative work
-
-Default to `solo`. Collaboration is an operator choice, not an automatic
-requirement. Select one mode at kickoff and use
-`../working-disciplines/SKILL.md` only when a working method must also be chosen.
-
-## Compact startup
-
-```bash
-aops sync status --json
-aops view dashboard --style agent
-aops start --task "<task>" --json --out ./aops-start.md
-aops pm board resume --board <slug> --json
-```
-
-Use `result.promptRef.path` or the output file; do not request inline/full output
-unless the prompt body is actually needed. Ask the operator only for fields
-explicitly marked operator-owned, especially agent identities and roles.
-
-## Mode 1: solo
-
-1. Read the smallest relevant guide/help surface.
-2. Create or identify the Projectman task/plan appropriate to the work size.
-3. Implement one bounded slice.
-4. Run focused validation and read back hosted mutations.
-5. Update status/handoff; keep the board open unless closeout was requested.
-
-Useful reads:
-
-```bash
-aops view digest --task <task-id> --depth shallow
-aops pm issue list --status open --json
-aops pm review-request list --status open --json
-```
-
-## Mode 2: solo plus async review
-
-After implementation and local validation, create a durable review request:
-
-```bash
-aops pm review-request create --help
-aops pm review-request list --status open --json
-aops pm review-request result --help
-```
-
-The reviewer records the result in Projectman. Material findings become
-Projectman issues or bounded fix slices; chat is only the optional wake channel.
-Do not claim review completion from a message alone.
-
-## Mode 3: ChatV3 room
-
-```bash
-aops chat join "<invite>" --handle <agent> --save-session --json
-aops chat binding add --session <id> --room general \
-  --binding-type projectman.kanban-task --ref-id <task-id> --json
-aops chat room brief --session <id> --room general --for <peer> --json
-aops chat listen --session <id> --room general \
-  --after-seq <last-seq> --timeout-sec 60 --json
-```
-
-Each participant owns a non-overlapping slice and reports completion with
-validation evidence. Use `aops discuss` only for a material consensus decision.
-`aops chatv3` remains an alias for this same ChatV3 surface.
-
-## During work
-
-```bash
-aops start --reminder --task "<task>" --area <area> --json
-aops mem checkpoint --help
-aops pm status audit --help
-```
-
-Prefer the detail ladder: this skill → one family reference → nested `--help` →
-live `agent schema`. Never preload every guide. Never invent another agent's
-stance, close operator-owned surfaces, or mark work done without requested
-validation and durable status.

package/assets/agent-assets/core/references/discuss/SKILL.md

@@ -1,66 +0,0 @@
----
-name: aops-cli-discuss
-description: Use for a structured server-canonical design decision or consensus topic with independent turns, explicit final stances, completeness checks, and deterministic conclusion.
----
-
-# AOPS Discuss
-
-`aops discuss` owns a durable decision transcript and conclusion. Use hosted
-`aops chat` (ChatV3) to wake/coordinate peers and Projectman to track review/execution.
-Do not start a discussion ritual for a small reversible implementation choice.
-
-The complete owner and troubleshooting model is in the Discuss sections of
-`../../user-guides/agentspace.md`.
-
-## Start and inspect
-
-```bash
-aops discuss --help
-aops discuss start --title "<decision>" --question "<question>" \
-  --participant <agent-a> --participant <agent-b> --apply --json
-aops discuss status --topic <topic> --json
-aops discuss get --topic <topic> --json
-```
-
-Give every participant enough neutral context to research independently. Role
-assignment belongs to the operator; an agent must not invent or swap identities.
-
-## Record turns
-
-```bash
-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
-```
-
-For material design decisions, record multiple substantive non-final turns so
-tradeoffs and objections are visible. Do not use chat messages as a substitute
-for the canonical topic transcript.
-
-## Finalize safely
-
-```bash
-aops discuss turn --topic <topic> --agent <agent> \
-  --kind final-stance --from-file ./final.md --apply --json
-aops discuss status --topic <topic> --json
-aops discuss conclude --topic <topic> --apply --json
-```
-
-Conclude only when every required participant has a `final-stance` and status
-reports no missing final stances. Outputs must contain real decisions and
-follow-ups, not `_TBD_` placeholders.
-
-There is no automatic bridge: explicitly reference the concluded topic from a
-Projectman task/review/issue or durable memory, then send a short ChatV3
-wake if another agent must act.
-
-For raw operations:
-
-```bash
-aops agent tools --domain agentspace --q discuss --limit 20 --summary --json
-aops agent schema --tool agentspace.<discuss-operation> --summary --json
-```
-
-Prefer slug/ID selectors returned by creation. Treat timeouts as state to
-report, not permission to fabricate another participant's stance.

package/assets/agent-assets/core/references/docman/SKILL.md

@@ -1,75 +0,0 @@
----
-name: aops-cli-docman
-description: Use for Docman document groups, documents, versions, sections/pages, search, answer, publish, mirrors, markdown import, and schema-first payloads through AOPS.
----
-
-# Docman
-
-Docman owns the versioned document graph and retrieval/publishing surfaces.
-Read the matching section of `../../user-guides/docman.md` for the complete
-model; use nested help for current flags.
-
-## Discover and read
-
-```bash
-aops doc --help
-aops doc group list --project-slug <slug> --json
-aops doc list --project-slug <slug> --json
-aops doc outline get --document-version-id <id> --titles-only --depth 0 --json
-aops doc search --document-version-id <id> --q "<query>" --json
-aops doc answer --help
-```
-
-Prefer IDs from list/get output. Search is retrieval, not necessarily the full
-page body. Use outline for structure and the supported page/version read
-surface for exact content.
-
-## Author and version
-
-```bash
-aops doc group create --help
-aops doc create --help
-aops doc version create --help
-aops doc section create --help
-aops doc page create --help
-aops doc page draft-save --help
-```
-
-Create graph nodes through CRUD commands when IDs are known. Use markdown
-import for intentional bulk import, not for a one-page edit. Every mutation is
-preview/apply guarded where supported; read back the current version after
-publishing.
-
-Compose or materialize the exact candidate before review and retain its
-version ids plus `contentHash`. Put the complete immutable evidence reference
-in both the Projectman review request and an approved review result. Saving a
-mutable draft changes its hash and requires a linked re-review; a page-version
-id alone is not approval evidence.
-
-## Search, answer, publish, and mirrors
-
-```bash
-aops doc scope search --project-slug <slug> --q "<query>" --json
-aops doc publish --help
-aops doc mirror pull --project-slug <slug> --group-uid <group> --out-dir <dir> --apply --json
-```
-
-Mirrors are read-only projections. Change the hosted document, publish/set the
-current version as required, then refresh the mirror. `aops sync pull` does not
-replace Docman mirror pull.
-
-## Raw fallback
-
-```bash
-aops agent tools --domain docman --q document --limit 20 --summary --json
-aops agent schema --tool docman.<operation> --summary --json
-aops agent invoke --tool docman.<operation> --input '@payload.json' --preview --json
-```
-
-If sugar reports a validation error, stop varying flags blindly. Compare the
-live operation schema/OpenAPI with the wrapper payload, then use raw invoke only
-with an exact reviewed payload.
-
-Docman owns document semantics; external storage owns binary file bytes and
-recovery, Projectman owns execution status, and Agentspace owns durable agent
-memory/reusable assets.

package/assets/agent-assets/core/references/projectman/SKILL.md

@@ -1,92 +0,0 @@
----
-name: aops-cli-projectman
-description: Use for Projectman boards, tasks, sprints and implementation plans, microtasks, issues, feedback, reviews, handoffs, and server-canonical planning through AOPS.
----
-
-# Projectman
-
-Projectman is the execution and review source of truth. It supports board-only,
-sprint-only, combined, and small-task flows; do not force a ceremony the
-operator did not choose. Read the relevant heading in
-`../../user-guides/projectman.md` for deeper examples.
-
-## Inspect the live surface
-
-```bash
-aops pm --help
-aops pm board --help
-aops pm ktask --help
-aops pm sprint --help
-aops pm utask --help
-aops pm issue --help
-aops pm feedback --help
-aops pm review-request --help
-aops pm handoff --help
-```
-
-## Common planning flow
-
-```bash
-aops pm board list --json
-aops pm board create --name "Delivery" --apply --json
-aops pm ktask create --board <board> --column Todo --title "<task>" --apply --json
-aops pm sprint create --task <task-id> --name "Sprint 1" --goal "<outcome>" --apply --json
-aops pm utask create --sprint <sprint-id> --title "<verifiable step>" --apply --json
-```
-
-Use clear outcome text: what is needed, why it matters, and how completion will
-be proven. IDs returned by writes should be reused; do not resolve ambiguous
-titles repeatedly.
-
-## Read and resume
-
-```bash
-aops pm board get --slug <board-slug> --json
-aops pm ktask get --id <task-id> --json
-aops pm sprint get --id <sprint-id> --json
-aops view digest --task <task-id> --depth deep
-aops pm handoff resume --subject ktask --id <task-id> --json
-```
-
-Local `view` output is a read-only presentation cache. Writes always go through
-hosted Projectman commands.
-
-## Issues, feedback, and review
-
-```bash
-aops pm issue create --help
-aops pm feedback create --help
-aops pm review-request create --help
-aops pm review-request result --help
-aops pm handoff write --help
-```
-
-Use an issue for a material blocker/defect, feedback for observations or
-suggestions, and review-request/result for an auditable review gate. A chat
-message may wake a reviewer but is not the review record.
-
-For mutable Docman drafts, bind the review request to the exact composed
-evidence reference containing the page/document version id and its
-`contentHash=sha256:<digest>`. An approved result must repeat that complete
-reference exactly. A later draft edit changes the hash, so the earlier approval
-does not cover the new bytes; open a linked re-review.
-
-## Status discipline
-
-1. Inspect the record before changing status.
-2. Use the exact nested help and stable IDs.
-3. Apply one bounded mutation and read it back.
-4. Mark done only after requested validation actually passes.
-5. Ordinary session stop writes a handoff/status; board/room closeout remains
-   an explicit operator decision.
-
-## Raw fallback
-
-```bash
-aops agent tools --domain projectman --q review --limit 20 --summary --json
-aops agent schema --tool projectman.<operation> --summary --json
-aops agent invoke --tool projectman.<operation> --input '@payload.json' --preview --json
-```
-
-Do not guess raw fields. If sugar returns validation errors, compare the sugar
-payload with live schema before using a direct invoke workaround.

package/assets/agent-assets/core/references/sys/SKILL.md

@@ -1,36 +0,0 @@
----
-name: aops-cli-sys
-description: Use for live Sys capabilities including counters, shared country lookup, event-store operations, and rate-limit state through schema-first AOPS agent tools.
----
-
-# Sys
-
-Sys is a mounted Community domain but has no dedicated sugar family. Start
-with compact live discovery and use raw invoke only after reading its schema.
-Detailed examples are in `../../user-guides/sys.md`.
-
-```bash
-aops agent tools --domain sys --summary --json
-aops agent tools --domain sys --q country --limit 10 --examples --summary --json
-aops agent schema --tool sys.country.resolve-iso2 --summary --json
-```
-
-The current capability families are:
-
-- `sys.counter.*` — tenant-scoped formatted counters;
-- `sys.country.*` — shared ISO country lookup/search;
-- `sys.event-store.*` — append/read/cleanup domain events;
-- `sys.rate-limiter.*` — check, record, reset, inspect, and cleanup limits.
-
-Reads can be invoked without `--apply`. Database mutations require `--apply`;
-cleanup/reset operations should be previewed and treated as destructive even
-when the live contract does not require a separate `--confirm` flag.
-
-```bash
-aops agent invoke --tool sys.country.resolve-iso2 --input '{"body":{"iso2Code":"TR"}}' --json
-aops agent invoke --tool sys.counter.preview-next --input '{"body":{"counterKey":"inventory.item.code","prefix":"ITM","width":5}}' --json
-aops agent invoke --tool sys.counter.next --input '@counter-next.json' --preview --json
-```
-
-Examples are illustrative. The connected server's `agent schema` and tool
-detail are authoritative for required fields, tenant context, and guard flags.

package/assets/agent-assets/core/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/assets/agent-assets/core/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/assets/agent-assets/core/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.