@awebai/pi 0.1.12 → 0.1.14

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@awebai/pi",
-  "version": "0.1.12",
+  "version": "0.1.14",
   "description": "Aweb for Pi: real-time channel awakenings, aw CLI onboarding, and aweb skills.",
   "type": "module",
   "main": "./dist/index.js",

package/skills/aweb-bootstrap/SKILL.md

@@ -159,7 +159,7 @@ Supported sources:
 
 Decision recipe:
 
-- Human says “make me a new team” and has no existing aw context: use hosted (`--username` or interactive prompt).
+- Human says “make me a new team” and has no existing aw context: use hosted (`--username` or interactive prompt). If using `--yes`, include `--username`; otherwise omit `--yes` so hosted onboarding can prompt.
 - Human has a dashboard/API key: use `AWEB_API_KEY=... aw team bootstrap ...`; do not ask for `AWEB_URL` unless they are using a non-default stack.
 - Human pasted an invite: use `--invite-token`.
 - Human is already inside the team workspace that should own the new agents: use current workspace forwarding (no explicit source).
@@ -171,7 +171,7 @@ Policy guidance:
 - Prefer API key or invite when the team already exists but the caller is not already inside it.
 - Prefer current workspace forwarding when you are already inside the target team.
 - Prefer BYOT when you need local control over the team namespace/domain and routing.
-- Use `--dry-run` for planning only. The old manual "print commands after installing server state from caller cwd" flow is not coherent and should not be recommended.
+- Use `--dry-run` for planning only. It prints the resolved plan (template ref, work directory, team source, generated workspaces) without writing identities, files, or server state. Do not pair it with side-effecting flags expecting partial provisioning.
 
 ## Worktree agents (team.yaml worktrees:)
 

package/skills/aweb-bootstrap/references/bootstrap-scenarios.md

@@ -30,13 +30,13 @@ Checklist:
   - awebai/aweb-team-dev-review for a minimal 2-agent setup.
   - awebai/aweb-team-company-surfaces for a 6-agent cross-functional setup.
 
-Example (using an existing local work directory):
+Example (using an existing local work directory, with an explicit hosted username so --yes does not need prompts):
 
-  aw team bootstrap https://github.com/awebai/aweb-team-dev-review.git --yes --work-directory /path/to/work
+  aw team bootstrap https://github.com/awebai/aweb-team-dev-review.git --yes --username alice --work-directory /path/to/work
 
 Example (clone the work repo into the template checkout):
 
-  aw team bootstrap https://github.com/awebai/aweb-team-dev-review.git --yes --work-repo-url https://github.com/ORG/REPO.git
+  aw team bootstrap https://github.com/awebai/aweb-team-dev-review.git --yes --username alice --work-repo-url https://github.com/ORG/REPO.git
 
 Notes:
 

package/skills/aweb-team-membership/SKILL.md

@@ -226,7 +226,33 @@ aw id team add-member --team <team> --namespace <domain> --did <beta_did_key> --
 
 Use the actual `did`/`did_aw` values printed by `aw id create`. Do not guess them.
 
-Import into aweb cloud:
+Register with aweb cloud without using the dashboard:
+
+```bash
+aw id team register --service https://app.aweb.ai --team <team>:<domain>
+```
+
+This signs a service-registration request with the team controller key. It creates or syncs an aweb projection of the AWID team, but it does not upload controller private keys, create identities, or initialize any agent workspace. Read the returned next steps and run the required `aw service init` command from each already-certified agent directory:
+
+```bash
+aw service init --service https://app.aweb.ai --team <team>:<domain>
+```
+
+`aw service init` requires the local `.aw/signing.key`, `.aw/teams.yaml`, and `.aw/team-certs/*.pem` for that agent. If the certificate is not installed yet, fetch it first with the certificate id returned by `aw id team add-member`:
+
+```bash
+aw id team fetch-cert --namespace <domain> --team <team> --cert-id <cert-id>
+```
+
+After at least one workspace is initialized, the service may suggest a human-claim command such as:
+
+```bash
+aw claim-human --email you@example.com
+```
+
+`claim-human` is a service-account/human-login step for billing and dashboard ownership. It is not AWID team-controller authority and it does not add members to the BYOT team.
+
+Import into an existing aweb organization:
 
 1. In app.aweb.ai, create or select the owner organization that should contain the imported team.
 2. Open the BYOT import flow. Prefer the command shown by the dashboard because it contains the correct `--organization-id`.

package/skills/aweb-team-membership/references/team-membership-reference.md

@@ -51,7 +51,7 @@ Addressability and delivery authorization are separate:
 - `did:aw` is identity binding, not a first-contact delivery route.
 - `inbound_mode=open|team_and_contacts` controls delivery after route validation.
 - `team_and_contacts` accepts verified same-team senders plus exact active identity contacts for trusted non-team senders. Contacts do not create routes or resolver visibility.
-- Legacy reachability fields may still appear in support or migration output, but they are compatibility/audit state, not live delivery authority.
+- Reachability fields that appear in support or migration output are compatibility/audit state, not live delivery authority.
 - `aw contacts ...` manages saved contact relationships.
 - `aw id namespace resolve <domain>/<alias> --json` performs a workspace-free directory lookup.