Merge refactor bad760ce0 into U0 samples
This commit was merged in pull request #1880.
This commit is contained in:
jason.woltje committed
commit
2bed0aebeb
305 files changed
+7807
-5510
No files matched your search
+15
-7
@@ -251,16 +251,24 @@ Exit codes: `0` ok · `1` failed · `2` invalid or refused · `3` uncertain,
|
||||
retry the same op (for a review request, the retry sends nothing; resolve or
|
||||
abandon it) · `4` usage. Details: `packages/queue/README.md`.
|
||||
|
||||
## Business files and role instances (`scripts/mosaic business`)
|
||||
## Organization files and role instances (`scripts/mosaic org config`, `scripts/mosaic org instances`)
|
||||
|
||||
```bash
|
||||
scripts/mosaic business validate <business>
|
||||
scripts/mosaic business resolve <business> <instance> [--project <id>]
|
||||
scripts/mosaic business instances <business> [--json]
|
||||
scripts/mosaic business instance add <business> <instance> --definition <def> [--vars <file>] [--launch] --revision <rev>
|
||||
scripts/mosaic business instance set <business> <instance> [--definition <def>] [--vars <file>] [--launch | --no-launch] --revision <rev>
|
||||
scripts/mosaic org config validate <org>
|
||||
scripts/mosaic org config resolve <org> <instance> [--project <id>]
|
||||
scripts/mosaic org instances <org> [--json]
|
||||
scripts/mosaic org instance add <org> <instance> --definition <def> [--vars <file>] [--launch] --revision <rev>
|
||||
scripts/mosaic org instance set <org> <instance> [--definition <def>] [--vars <file>] [--launch | --no-launch] --revision <rev>
|
||||
```
|
||||
|
||||
`scripts/mosaic business validate|resolve|instances|instance|veto` is the old
|
||||
spelling of these commands, with the same arguments, and it still works. Both
|
||||
spellings run the same code and give the same status, stdout and stderr.
|
||||
Only a validate/resolve usage error differs: it prints the usage of the
|
||||
spelling you used. Every other validate/resolve stderr line, refusals and
|
||||
warnings included, starts `mosaic business: ` in both spellings. `scripts/mosaic org validate FILE` is a different command: it
|
||||
checks a draft file by path and prints `valid`.
|
||||
|
||||
Reads `businesses/<business>.json` next to the system config
|
||||
(`$MOSAIC_CONFIG` or `~/.config/mosaic-dev/`), the version 2 role files in
|
||||
`roles/` (or `$MOSAIC_ROLES_DIR`) and each project's `.mosaic/project.json`.
|
||||
@@ -271,7 +279,7 @@ its narrowed tools, network and authority, and its credential references.
|
||||
The business file must belong to you and not be group or other writable.
|
||||
Exit codes: `0` ok · `2` invalid file or credential reference · `3` system
|
||||
config problem · `4` usage or a required file missing. Details:
|
||||
`packages/business/README.md`.
|
||||
`packages/organization/README.md`.
|
||||
|
||||
`mosaic credentials status|issue|rotate|revoke|delete` (row 199) goes to
|
||||
`packages/cli` and the bus's human-only credential verbs: an agent's own
|
||||
|
||||
@@ -157,7 +157,7 @@ Kinds of work:
|
||||
| Talk `#/talk` | the conversation History view exists; the live PM session is row 41 | blocked | Row 41 (S6). Reuse the controller/observer rules of `packages/conversation` |
|
||||
| Queue `#/queue` | `packages/queue/src/store.mjs` `list`/`show`; no endpoint | new view | Read-only. Rows move only through `queue move` |
|
||||
| Ledger `#/ledger` | `packages/ledger` `summarize`, `queueChecks` | new view | Read-only |
|
||||
| Business `#/business` | `packages/business` `loadBusiness`, `loadRole`, `resolveInstance`, `vocabulary.mjs` | new view | Read-only. A missing or invalid file shows the refusal state. Credential refs as metadata only |
|
||||
| Business `#/business` | `packages/organization` `loadBusiness`, `loadRole`, `resolveInstance`, `vocabulary.mjs` | new view | Read-only. A missing or invalid file shows the refusal state. Credential refs as metadata only |
|
||||
| Runs and releases `#/runs` | readers live inside `scripts/mosaic-task.mjs` and `scripts/release.sh`, not exported | backend | Extract a read-only module first |
|
||||
| Library `#/library` | no meta-harness in committed code | blocked | Row 41 (S6) creates `packages/harness` |
|
||||
| Settings `#/settings` | appearance exists in the webui header; notifier config `readNotifyConfig` | extend | Appearance, notifications (binding names only), about (loopback, release). Read-only apart from appearance |
|
||||
|
||||
@@ -327,7 +327,7 @@ After install, `stack-copy.sh check --units external` reads the copy the units r
|
||||
|
||||
Before running `case2-install.sh`, check the exact file you will pass as `--business-file`. Each
|
||||
non-library `projects` key must equal the `id` in `<root>/.mosaic/project.json`, and that file must exist
|
||||
in the stack's user's clone. Library entries are skipped by validate (`packages/business/src/cli.mjs:72`).
|
||||
in the stack's user's clone. Library entries are skipped by validate (`packages/organization/src/config-command.mjs:95`).
|
||||
Run this read-only check as `mosaic` with section 2's pinned node:
|
||||
|
||||
```sh
|
||||
@@ -356,7 +356,7 @@ MOSAIC_PROJECT_KEYS
|
||||
For .53 expect `ok project stack: /srv/mosaic/src/mosaic-stack/.mosaic/project.json has id stack`
|
||||
(`.mosaic/project.json:3`, `docs/guides/case1-business.mosaic-stack.json:10-11`). Any STOP or nonzero exit
|
||||
stops the install. Fix a mismatched business key, not the project id (mos-1563). The install otherwise
|
||||
reaches that refusal at step 7, after making the copy (`packages/business/src/cli.mjs:80`,
|
||||
reaches that refusal at step 7, after making the copy (`packages/organization/src/config-command.mjs:103`,
|
||||
`scripts/case2-install.sh:178`, `scripts/case2-install.sh:217`).
|
||||
|
||||
The stack's user's `scripts/case2-install.sh` (C2-13b, design 10 step 2b) makes the first copy with
|
||||
@@ -365,7 +365,7 @@ harness, so the host needs to reach the npm registry during the install. The ins
|
||||
`release.sh package` or `activate`.
|
||||
|
||||
A missing `.mosaic/project.json` only warns: `project <id>: no project file at <path>; it has no project
|
||||
variables`. Validate reports that project `absent` and continues (`packages/business/src/cli.mjs:74-78`).
|
||||
variables`. Validate reports that project `absent` and continues (`packages/organization/src/config-command.mjs:97-101`).
|
||||
An install can therefore pass step 7 without the project's variables. It captures validate's output
|
||||
and prints `business <id> validates` (`scripts/case2-install.sh:217-221`). Treat the missing-file warning as a stop,
|
||||
place the correct project file and repeat the check above before continuing (Duckworth 323 N2;
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# PRD version 1.20, draft 1: unified workspace
|
||||
# PRD version 1.20, draft 2: unified workspace
|
||||
|
||||
- Status: draft, not approved. Jason approves the exact text before it
|
||||
enters `docs/prd/mosaic-stack.md` as version 1.20.
|
||||
@@ -100,9 +100,13 @@ need no sign-in.
|
||||
- **REQ-AGENT-2.** The user can see and change the configuration of agents,
|
||||
organizations, projects and sessions, and can override any setting at any
|
||||
time, through the write path (REQ-ROLE-3).
|
||||
- **REQ-AGENT-3.** The chief of staff hires and fires agents at the
|
||||
organization and project levels under REQ-COS-3. Root-level agents change
|
||||
only by the user.
|
||||
- **REQ-AGENT-3.** The chief of staff hires and fires agents to meet the
|
||||
user's needs. At the organization and project levels it acts under
|
||||
REQ-COS-3. At the root level its hire or fire changes the user's root
|
||||
configuration, which every organization of that user sees, so it reaches
|
||||
outside the chief's own organization. A root-level hire or fire is a
|
||||
decision the user approves in the inbox (REQ-DEC-2) before it takes
|
||||
effect. The user can also change root-level agents directly.
|
||||
|
||||
### System types
|
||||
|
||||
@@ -131,6 +135,10 @@ need no sign-in.
|
||||
|
||||
## Open questions for the approval
|
||||
|
||||
1. The final name for the Mosaic Montage module.
|
||||
2. REQ-AGENT-3 keeps root-level agents user-only. Should the chief of staff
|
||||
also be able to propose root-level hires for the user to approve?
|
||||
1. The final name for the Mosaic Montage module. A council of three agents
|
||||
is producing three suggestions for Jason to choose from.
|
||||
2. Answered 2026-11-09: "yes, the COS should be able to hire and fire
|
||||
agents to fulfill the user's needs". REQ-AGENT-3 now lets the chief hire
|
||||
and fire at every level. Draft 2 keeps one approval step at the root
|
||||
level because a root change reaches every organization; Jason can drop
|
||||
that step when he approves the text.
|
||||
@@ -273,3 +273,18 @@ report's recommendations, and Jason can overturn any of them:
|
||||
- The final name for the Mosaic Montage module (deferred by Jason, 11-09).
|
||||
- Which "sign-in (model proxy)" step Jason hit. F3 inventories every manual
|
||||
step on the dev instance and reports it.
|
||||
|
||||
## Addendum, 2026-11-09 18:13 UTC
|
||||
|
||||
Jason's answers to the two open questions in PRD 1.20 draft 1, verbatim:
|
||||
|
||||
> 1. I would like you to use a council of agents to decide on 3 name
|
||||
> suggestions for this
|
||||
> 2. yes, the COS should be able to hire and fire agents to fulfill the
|
||||
> user's needs
|
||||
|
||||
Effect: the chief of staff hires and fires agents at the root,
|
||||
organization and project levels (PRD 1.20 draft 2, REQ-AGENT-3). A council
|
||||
of three agents proposes three names for the Mosaic Montage module, and
|
||||
Jason picks one.
|
||||
|
||||
Reference in new issue
Block a user