@dayofweek/dcli 1.5.0 → 1.7.0

package/README.md

@@ -72,6 +72,34 @@ Updates overwrite only files whose installed hash still matches the managed mani
 
 The legacy entity/proposal Agent Skill remains available through `dcli skill install` without a bundle name.
 
+### Shared skills
+
+Beyond the named bundles above, users can publish their own skills into a shared knowledge area. Anyone who can read the area — or, with `--visibility company`, anyone in the publishing area's organization — can then discover, install, and update the skill. Service administrators can additionally publish with `--visibility global`, making a skill a shared starter for every user of the service; the desktop app syncs global skills into managed wikis automatically.
+
+```bash
+# Publish a local skill directory (name/version come from SKILL.md frontmatter)
+dcli skill publish --area <areaId> --dir .agents/skills/meeting-notes --visibility company
+
+# Discover: --shared adds skills shared with you to the bundle listing
+dcli skill list --shared --json
+
+# Install by canonical URI, or by name + area
+dcli skill install 'dayofweek://brain/<areaId>/skill/<skillId>'
+dcli skill install meeting-notes --area <areaId>
+
+# Update goes back to wherever the install came from
+dcli skill update meeting-notes --area <areaId>
+dcli skill update --dir .agents/skills/meeting-notes
+
+# Check for newer versions without writing anything
+dcli skill status meeting-notes --dir .agents/skills/meeting-notes --check
+
+# Retire a shared skill you own
+dcli skill archive 'dayofweek://brain/<areaId>/skill/<skillId>'
+```
+
+Shared skills go through the same integrity pipeline as named bundles: per-file SHA-256 plus a manifest hash computed server-side and re-verified locally before anything touches disk, the same path-safety rules, and the same conflict handling — locally edited files are never overwritten. The install origin is recorded in `.dayofweek-skill.json`, so `skill update` and `skill status --check` know whether to ask the bundle endpoint or the shared-skill endpoint. Publishing requires write access to the area; `--visibility company` and `skill archive` require ownership.
+
 ## URI contract
 
 `dcli` accepts only exact canonical resource forms:
@@ -111,6 +139,55 @@ immediately, so treat them as something you do when a person has asked for that
 specific document — not as the normal path. The server rejects them for
 non-admin tokens.
 
+## Datasets
+
+The platform offers additional read-only datasets beyond entities and
+knowledge. The catalog is server-owned and discovered at runtime — what
+`data list` returns is exactly what your credential may read.
+
+```bash
+dcli data list --json
+dcli data get <dataset> --limit 100 --json
+```
+
+Responses are `{ dataset, total, truncated, rows }`. The CLI has no built-in
+dataset names; new datasets appear in the listing without a CLI update.
+
+## Feedback backlog
+
+The customer feedback backlog that humans and coding agents work together.
+
+```bash
+dcli feedback next --json                    # what should I work on next
+dcli feedback list --status backlog --json
+dcli feedback show <itemId> --json
+dcli feedback claim <itemId> --json          # signal that you picked it up
+dcli feedback comment <itemId> --body "Fixed in #482"
+dcli feedback status <itemId> --status shipped
+```
+
+Access follows the token's scopes: `read:feedback` for the reads,
+`write:feedback` to comment, `admin:feedback` for claim/status/priority.
+Day of Week staff hold all three implicitly.
+
+## Customer emails (staff)
+
+Mail sent to a customer's own inbox address becomes a thread you can answer.
+The commands appear once `dcli auth status` has cached your admin role.
+
+```bash
+dcli emails list --status needs_reply --json
+dcli emails show <threadKey> --json
+dcli emails reply <threadKey> --message "..." --approved
+dcli emails compose --entity <entityId> --to person@example.com \
+  --subject "..." --message "..." --approved
+```
+
+`reply` and `compose` refuse to run without `--approved`. Sending mail as a
+customer is irreversible and outward-facing, so it cannot happen as a side
+effect of reading the inbox — a person approves the exact text first, and
+`--approved` records that they did.
+
 ## Legacy platform commands
 
 Existing read/proposal workflows remain compatible:
@@ -135,11 +212,31 @@ Development commands:
 ```bash
 npm install
 npm test
-npm run build
+npm run build            # tsc + the dependency-free bundle
+npm run build:bundle     # just dist/bundle/dcli.cjs
 npm run standalone:build
 npm run standalone:smoke
 ```
 
+### What gets published
+
+`npm run build` produces two runnable forms, and both ship:
+
+- **`dist/bin/dcli.js`** — the normal entry point, the one `bin` points at. It
+  imports `commander` and `open` from `node_modules`, which is exactly right
+  when npm installed the package.
+- **`dist/bundle/dcli.cjs`** — the same CLI with its dependencies compiled in,
+  runnable straight from an unpacked tarball.
+
+The bundle exists for consumers that unpack the tarball themselves instead of
+installing it, the Day of Week desktop app being the one that matters: it fetches
+the published package and runs it with Electron's Node, so a customer with no
+`node` and no `npm` still gets a working `dcli`. Without the bundle that install
+starts and immediately fails on a missing `commander`.
+
+Keep both. Dropping `dist/bundle/` from `files` silently breaks the desktop app's
+dcli updates.
+
 ## License
 
 MIT