@aopslabs/aops 0.3.4 → 0.3.5

package/agent-assets-release/agent-assets/core/8b06775d96e37f8aef535673b8b855c11f29042f3c70ec4f273b6df04dbe824a/files/references/projectman/SKILL.md

@@ -0,0 +1,86 @@
+---
+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.
+
+## 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/agent-assets-release/agent-assets/core/8b06775d96e37f8aef535673b8b855c11f29042f3c70ec4f273b6df04dbe824a/files/references/sys/SKILL.md

@@ -0,0 +1,36 @@
+---
+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/agent-assets-release/agent-assets/core/8b06775d96e37f8aef535673b8b855c11f29042f3c70ec4f273b6df04dbe824a/files/references/view/SKILL.md

@@ -0,0 +1,58 @@
+---
+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/8b06775d96e37f8aef535673b8b855c11f29042f3c70ec4f273b6df04dbe824a/files/references/working-disciplines/SKILL.md

@@ -0,0 +1,69 @@
+---
+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 | Mission 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
+```
+
+Inspect `result.mission.policyJson` and persist it only if a durable mission is
+appropriate:
+
+```bash
+aops mission create --objective "<objective>" \
+  --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 hosted 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 mission/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/8b06775d96e37f8aef535673b8b855c11f29042f3c70ec4f273b6df04dbe824a/files/user-guides/agent-assets.md

@@ -0,0 +1,81 @@
+# 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.