@seliseblocks/cli-os 0.2.10 → 0.2.12

package/dist/skills/blocks-data-storage/SKILL.md

@@ -1,253 +0,0 @@
----
-name: blocks-data-storage
-description: "Build file and document-management features on SELISE Blocks Data: upload/download, directory trees, cursor-paginated browsing and search, file versions, rename/move/copy, soft delete/trash/restore, sharing, access policies, and inheritance. Use for attachments, file browsers, folders, shared files, permissions, or version history. Use 'blocks data files *' for terminal/admin work and @seliseblocks/client data.files/data.directories/data.objects for app code."
----
-
-# Blocks Data — Storage
-
-Treat storage as one permission-aware object tree containing **directories** and **files**. Uploading a new file now creates the file object in that tree; there is no second DMS registration step.
-
-Use:
-
-- **`blocks data files *`** for supported terminal/admin operations.
-- **`@seliseblocks/client`** for app code. Use the shared `blocksClient` created by blocks-onboarding.
-- **blocks-storage-configuration** only to manage the named provider configuration used by `configurationName`.
-
-Select a project first with `blocks use <tenantId>`. If login/project state or the shared client setup is unknown, use blocks-onboarding before this skill.
-
-Store the returned `fileId` in a Data record when attaching a file to domain data. Use blocks-data-gateway-crud for the record mutation.
-
-## Choose the surface
-
-The current CLI and SDK follow the backend's file, directory, and object resource groups.
-
-```bash
-blocks --version
-blocks data files --help
-```
-
-- Use `blocks data files *` for terminal/admin work and inspect `blocks --help` for exact flags.
-- Use `blocksClient.data.files` for bytes, metadata, versions, and file operations.
-- Use `blocksClient.data.directories` for directory create/get/update/delete/move.
-- Use `blocksClient.data.objects` for browse/search/trash/shared/restore/share/access/inheritance.
-
-Legacy `data.dms.*`, `dms-upload`, `dms-list`, `create-folder`, and `delete-folder` wrappers are retired. Uploads need no registration call.
-
-## Upload a new file
-
-Choose one path from the project's storage configuration.
-
-| Provider category | Sequence |
-|---|---|
-| Cloud object storage | request a pre-signed URL, then PUT the bytes to it |
-| Local/SFTP storage | send one authenticated multipart upload |
-
-Both paths create the file object and initial version directly. Do not call `dms-upload` afterward.
-
-### Cloud upload from the CLI
-
-Prefer the composed command. It previews and confirms both metadata creation and the provider PUT:
-
-```bash
-blocks data files upload --file ./invoice.pdf --parent-id <directoryId> \
-  --configuration-name Default --access-modifier Private --dry-run --json
-blocks data files upload --file ./invoice.pdf --parent-id <directoryId> \
-  --configuration-name Default --access-modifier Private --yes --json
-```
-
-Use the two explicit commands only when the intermediate upload URL is required:
-
-```bash
-blocks data files presigned-upload-url \
-  --name invoice.pdf \
-  --parent-directory-id <directoryId> \
-  --configuration-name Default \
-  --access-modifier Private \
-  --dry-run --json
-blocks data files presigned-upload-url \
-  --name invoice.pdf \
-  --parent-directory-id <directoryId> \
-  --configuration-name Default \
-  --access-modifier Private \
-  --yes --json
-
-blocks data files upload-to-url \
-  --url "<uploadUrl>" \
-  --file ./invoice.pdf \
-  --content-type application/pdf \
-  --dry-run --json
-blocks data files upload-to-url \
-  --url "<uploadUrl>" \
-  --file ./invoice.pdf \
-  --content-type application/pdf \
-  --yes --json
-```
-
-The presign response contains `uploadUrl`, `fileId`, and `isSuccess`. The first call creates the file metadata/version; the PUT fills its object-storage key. Handle PUT failure explicitly because it can leave metadata for missing bytes.
-
-When `parentDirectoryId` is empty, the cloud upload resolves `moduleName` to that module's default directory. The backend default is module value `8` (`Default_Construct`), but pass the intended module or a concrete directory id instead of relying on that default.
-
-### Cloud upload from app code
-
-```ts
-const presign = await blocksClient.data.files.presignedUploadUrl({
-  name: "invoice.pdf",
-  parentDirectoryId: directoryId,
-  configurationName: "Default",
-  accessModifier: "Private",
-  tags: "invoice,2026",
-});
-
-if (!presign || typeof presign !== "object") {
-  throw new Error("Unexpected upload response");
-}
-
-const result = presign as {
-  uploadUrl: string;
-  fileId: string;
-  isSuccess: boolean;
-  errors?: Record<string, string>;
-};
-
-if (!result.isSuccess) throw new Error(JSON.stringify(result.errors));
-
-await blocksClient.data.files.uploadToUrl({
-  url: result.uploadUrl,
-  body: file,
-  contentType: file.type || "application/octet-stream",
-});
-```
-
-`uploadToUrl` is provider-direct and sends no bearer token or `x-blocks-key`. The SDK adds Azure's `x-ms-blob-type: Blockblob` header unless overridden; ensure that header matches the signed provider policy.
-
-### Local-storage upload
-
-```bash
-blocks data files upload-to-local-storage \
-  --file ./invoice.pdf \
-  --parent-directory-id <directoryId> \
-  --configuration-name Default \
-  --access-modifier Private \
-  --dry-run --json
-blocks data files upload-to-local-storage \
-  --file ./invoice.pdf \
-  --parent-directory-id <directoryId> \
-  --configuration-name Default \
-  --access-modifier Private \
-  --yes --json
-```
-
-```ts
-const uploaded = await blocksClient.data.files.uploadToLocalStorage({
-  name: file.name,
-  file,
-  parentDirectoryId: directoryId,
-  configurationName: "Default",
-  accessModifier: "Private",
-  tags: ["invoice", "2026"],
-});
-```
-
-This call creates the file object and uploads version 1 in one request. Unlike cloud presign, an empty local `parentDirectoryId` stays at the top level; it is not resolved through `moduleName`.
-
-## Add a file version
-
-Supplying an existing `itemId` to either upload flow creates another version after the caller passes the file's Edit check. For cloud storage, the dedicated command/method returns another pre-signed URL:
-
-```bash
-blocks data files versions <fileId> --limit 25 --json
-blocks data files create-version <fileId> --configuration-name Default --dry-run --json
-blocks data files create-version <fileId> --configuration-name Default --yes --json
-```
-
-```ts
-const history = await blocksClient.data.files.versions({ fileId, limit: 25 });
-const next = await blocksClient.data.files.createVersion({ fileId, configurationName: "Default" });
-```
-
-Version history is newest-first and cursor-paginated. Use the returned opaque `nextCursor`; the current backend uses the last version number internally, but callers must not construct cursors. Limits are 1–100, default 25.
-
-## Read and download
-
-```bash
-blocks data files get <fileId> --configuration-name Default --json
-blocks data files get <fileId> --version <versionNo> --configuration-name Default --json
-blocks data files get-many <fileId...> --configuration-name Default --json
-```
-
-```ts
-const file = await blocksClient.data.files.get(fileId, {
-  configurationName: "Default",
-  version: 2,
-});
-```
-
-The response includes a download URL plus metadata. Download requires the caller's Download permission. Access-denied reads may deliberately look like missing resources so clients cannot probe hidden object ids.
-
-## Directory and object workflows
-
-For browsing, directories, search, move/copy/rename, trash, sharing, and ACL behavior, read [flows/object-management.md](flows/object-management.md).
-
-## Update custom metadata
-
-```bash
-blocks data files update-additional-info <fileId> \
-  --additional-properties '{"status":"reviewed"}' \
-  --dry-run --json
-blocks data files update-additional-info <fileId> \
-  --additional-properties '{"status":"reviewed"}' \
-  --yes --json
-```
-
-This updates `additionalProperties`; it does not rename, move, tag, or version the file.
-
-## Delete safely
-
-Deletion now distinguishes trash from permanent removal:
-
-- `permanent: false` archives the file or directory so it can be restored.
-- `permanent: true` removes it for good.
-- The backend default is **`true`** when `permanent` is omitted.
-
-The CLI defaults to safe soft deletion. Add `--permanent` only after explicit approval.
-
-```bash
-blocks data files delete <fileId> --dry-run --json
-blocks data files delete <fileId> --yes --json
-blocks data files delete <fileId> --permanent --dry-run --json
-```
-
-In app code, send the choice explicitly: `blocksClient.data.files.delete({ fileId, permanent: false })`.
-
-## Permission model
-
-Every storage request passes two checks:
-
-1. The endpoint permission permits that class of action.
-2. The object ACL permits the action on that specific file/directory.
-
-Capabilities are ordered: `View`, `Download`, `Edit`, `Delete`, `Manage`, `Owner`. Higher capabilities imply lower ones. Directory children inherit ancestor access while `inheritsParentAccess` is true. New files inherit from their directory.
-
-Do not infer permission from a visible button or endpoint grant. Render actions from each object's returned `permissions` flags and still handle 403/404 races.
-
-## Gotchas
-
-- Upload now creates the visible file object; legacy DMS registration is wrong and may fail after the bytes were successfully PUT.
-- Cloud presign creates metadata before the provider PUT. Treat the two steps as a recoverable workflow and surface partial failure.
-- A name must contain an allowed extension. Directories may restrict extensions.
-- Names are unique within a directory. File move/copy can fail on a name conflict or extension policy.
-- `Private` is the safe default. Use `Public` only when unauthenticated download is intended.
-- `configurationName` selects an existing provider record; it does not configure storage.
-- Most legacy file SDK methods return `Promise<unknown>`; validate responses at the boundary.
-- Never send Blocks auth headers to a pre-signed provider URL.
-- Never use a raw API call to work around a missing CLI/SDK wrapper; update the client surface first.
-
-## Example triggers
-
-- "Upload this PDF into the Contracts folder."
-- "Build a file browser with folders and search."
-- "Show files shared with the current user."
-- "Move this file to trash and let users restore it."
-- "Add version history and upload a replacement version."
-- "Share this directory with a role and let its children inherit access."
-- "Move, copy, or rename a file."

package/dist/skills/blocks-data-storage/flows/object-management.md

@@ -1,124 +0,0 @@
-# Object management
-
-Use `blocks data files *` from a terminal and `blocksClient.data.directories` / `blocksClient.data.objects` / `blocksClient.data.files` in app code. Do not fall back to legacy `data.dms.*` helpers or raw HTTP.
-
-## Browse a directory
-
-Use the current `get-objects` operation with:
-
-- `parentDirectoryId` for a concrete directory, or `moduleName` to resolve a module's default directory when no parent id is supplied.
-- `cursor` from the previous response and `limit` from 1–200 (default 50).
-- `type: "directory" | "file"` to narrow results.
-- `search` for name filtering within that parent.
-
-The result contains `items`, `nextCursor`, `hasMore`, and `totalChildCount`. Each item has a lowercase `type` discriminator and permission flags. Continue while `hasMore` using `nextCursor`; access filtering can produce a short page even when more results remain.
-
-Use `search-objects` for a case-insensitive name search across descendants. Pass `query`, optional `directoryId`, optional type, cursor, and limit. Search text is treated literally rather than as a regular expression.
-
-```bash
-blocks data files list --parent-id <directoryId> --type file --limit 50 --json
-blocks data files search invoice --directory-id <directoryId> --json
-```
-
-```ts
-const page = await blocksClient.data.objects.list({ parentDirectoryId, limit: 50 });
-const matches = await blocksClient.data.objects.search({ query: "invoice", directoryId });
-```
-
-## Manage directories
-
-- **Create:** provide `name`, an existing `parentDirectoryId`, optional `description`, `configurationName`, and `allowedFileExtensions`. If the parent is empty but `moduleName` is present, the backend resolves the module default. Creating a true root uses a separate owner-only capability and should not be a normal app action.
-- **Read details:** get one directory by `directoryId`. The response includes path, ancestors, child counts, size, extension rules, inheritance, timestamps, and permissions.
-- **Update:** provide `directoryId` and optional `name`/`description`. Default directories cannot be renamed.
-- **Move:** provide `directoryId` and `targetDirectoryId`; an empty target means top level. Moving into self/descendants is rejected. Default directories cannot move.
-- **Delete:** send `permanent: false` for trash. Permanent deletion requires an empty directory. Default directories cannot be deleted.
-
-Directory names must be 1–255 characters, trimmed, not `.`/`..`, and contain no slash or backslash. Descriptions are limited to 2,000 characters.
-
-```bash
-blocks data files directory-create Contracts --parent-id <directoryId> \
-  --allowed-extensions pdf,docx --dry-run --json
-blocks data files directory-get <directoryId> --json
-blocks data files directory-update <directoryId> --name Agreements --dry-run --json
-blocks data files directory-move <directoryId> --target-directory-id <targetId> --dry-run --json
-blocks data files directory-delete <directoryId> --dry-run --json
-```
-
-Use the matching `blocksClient.data.directories.create/get/update/move/delete` methods in app code.
-
-## Manage files
-
-- **Rename:** needs Edit and a unique name in the current directory.
-- **Move:** needs Delete on the source file and Edit on the target directory. Stored bytes and versions stay in place.
-- **Copy:** needs View on the source and Edit on the target. The new file gets a new id; version rows reference the same immutable stored bytes. It inherits from the target. Set `copyAccessPolicies` only when the user intends to duplicate direct policy entries.
-- **Versions:** list newest-first with a cursor and limit 1–100. Creating a cloud version returns `versionNo` and `uploadUrl`; PUT the bytes to that URL without Blocks auth headers.
-
-Move/copy reject a target name collision and a file extension disallowed by the target directory.
-
-```bash
-blocks data files rename <fileId> --name final.pdf --dry-run --json
-blocks data files move <fileId> --target-directory-id <targetId> --dry-run --json
-blocks data files copy <fileId> --target-directory-id <targetId> --dry-run --json
-```
-
-Use `blocksClient.data.files.rename`, `.move`, and `.copy` in app code.
-
-## Trash and restore
-
-Use soft delete (`permanent: false`) to archive an item. List archived files/directories with `get-trash`, optionally filtering by type and paging with cursor/limit. Restore with `restore-from-trash`; permanently purge an archived item with `delete-from-trash` only after explicit approval.
-
-Restore returns the item to its original parent. Reads and mutations remain ACL-filtered while the item is archived.
-
-```bash
-blocks data files trash --type file --json
-blocks data files restore <resourceId> --dry-run --json
-blocks data files purge <resourceId> --dry-run --json
-```
-
-Use `blocksClient.data.objects.trash`, `.restore`, and `.deleteFromTrash` in app code.
-
-## Shared objects
-
-Use `get-shared-objects` for live items shared with the caller. It is cursor-paginated and may be filtered by `directory`/`file`. Owned objects are excluded. Direct or inherited allow entries for the current user, role, or organization qualify as shares.
-
-Use `share-object` for the common allow-only action. Provide:
-
-- `resourceId`
-- `resourceType`: `Directory` or `File`
-- `principalType`: `User`, `Role`, `Organization`, or `Everyone`
-- `principalId` for every type except `Everyone`
-- `permission`: `View`, `Download`, `Edit`, `Delete`, `Manage`, or `Owner`
-- optional future `expiresAt`
-
-Sharing requires Manage on the resource.
-
-```bash
-blocks data files shared --json
-blocks data files share <resourceId> --resource-type Directory \
-  --principal-type Role --principal-id editors --permission Edit --dry-run --json
-```
-
-Use `blocksClient.data.objects.shared` and `.share` in app code.
-
-## Advanced access policies
-
-Use the policy operations only for an access-management UI:
-
-- `get-access-policies` lists direct entries on a resource.
-- `grant-access` adds Allow or Deny with optional priority and expiry.
-- `update-access-policy` replaces an entry and requires its `policyItemId`.
-- `revoke-access-policy` removes an entry by `resourceId` and `policyItemId`.
-- `resolve-access` returns the caller's `canView`, `canDownload`, `canEdit`, `canDelete`, `canManage`, and `canOwner` flags.
-- `toggle-inheritance` changes whether ancestors participate in resolution.
-
-Enums are JSON strings, not guessed numeric values. Priority must be non-negative and expiry must be in the future.
-
-Policy guardrails:
-
-- Manage is required to change access.
-- A Deny aimed at the resource owner is rejected.
-- Turning inheritance off is rejected until the resource has a direct Allow entry, preventing an orphaned resource.
-- The request model for access-policy listing contains `includeInherited`, but the current controller does not use it; do not promise inherited entries in that response. Use `resolve-access` for effective permissions.
-- Object reads may return 404 instead of 403 to avoid revealing hidden ids.
-
-CLI access commands are `access-list`, `access-grant`, `access-update`, `access-revoke`, `access-resolve`, and `inheritance`. Their SDK equivalents are under `blocksClient.data.objects`.

package/dist/skills/blocks-frontend-local-https/SKILL.md

@@ -1,100 +0,0 @@
----
-name: blocks-frontend-local-https
-description: "Run a scaffolded (`blocks new web`) Blocks app locally over HTTPS on its real project domain — required for hosted IAM login, since plain HTTP or localhost never gets the session cookie. The scaffold already automates cert generation (npm run cert, no OpenSSL needed) and HTTPS serving via vite.config.ts. Covers running that flow, trusting the cert, the hosts-file entry, and troubleshooting. Use when running a scaffolded app over HTTPS, hitting 'SSO cookie not set' / Vite 'Blocked request' errors, trusting the dev cert, or asking why local login redirects back but doesn't stay signed in."
----
-
-# Blocks Frontend — Local HTTPS for a Scaffolded App
-
-This is the local dev loop for an app already created with `blocks new web` (see the blocks-onboarding skill for the scaffold command itself — this skill doesn't repeat it). The scaffold **already generates its own cert tooling**; nothing here is built from scratch, and nothing uses raw `openssl`/`curl`/`fetch`.
-
-## Why localhost doesn't work
-
-Browser login goes through the hosted Blocks IAM IdP flow (`blocksClient.auth.idp.redirectToProvider()` / `.callback()`), which finishes by IAM setting a **Secure, domain-scoped session cookie**. Browsers won't store or send that cookie on plain `http://localhost` — it has to be HTTPS, and it has to be on the project's real domain, or the cookie silently never lands and the app looks "logged in" for a second then bounces back to logged-out.
-
-## Where the domain comes from
-
-`--app-domain` on `blocks new web` is the app's real Blocks origin, e.g. `https://dbpdba.seliseblocks.com`. The generated `.env` keeps two derived values:
-
-- `VITE_BLOCKS_APP_DOMAIN` — the full value as passed, with scheme (`https://dbpdba.seliseblocks.com`).
-- `VITE_BLOCKS_DEV_HOST` — the same host with no scheme (`dbpdba.seliseblocks.com`), computed by the scaffold generator and used everywhere locally: hosts file, cert `commonName`/SAN, and `vite.config.ts`'s `server.host`/`allowedHosts`.
-
-You never need to look this up separately — it's already sitting in `.env` after scaffolding.
-
-## The flow
-
-```bash
-cd <appName>
-npm install
-npm run cert
-```
-
-`npm run cert` runs `scripts/generate-cert.mjs`, which reads `VITE_BLOCKS_DEV_HOST` from `.env` (or `process.env`, or an explicit `npm run cert -- <domain>` argument) and uses the `selfsigned` npm dependency to write `.cert/dev-key.pem` and `.cert/dev-cert.pem`, with `subjectAltName` covering the domain, `localhost`, and `127.0.0.1`. This is pure Node — it works from a plain PowerShell prompt with no OpenSSL and no Git Bash/WSL switch.
-
-Next, map the domain to your machine — add one line to the hosts file (needs admin/elevated):
-
-```text
-127.0.0.1 dbpdba.seliseblocks.com
-```
-
-Windows path: `C:\Windows\System32\drivers\etc\hosts` (edit as Administrator).
-
-Then:
-
-```bash
-npm run dev
-```
-
-`vite.config.ts` picks up `.cert/dev-key.pem` + `.cert/dev-cert.pem` automatically when both exist and serves HTTPS on `VITE_BLOCKS_DEV_HOST`:`VITE_BLOCKS_DEV_PORT` (default port `5173`, `strictPort: true` because the port is baked into the registered OIDC redirect URI). It also sets `allowedHosts` to that domain, working around Vite's default DNS-rebinding protection which otherwise 404s custom hosts with "Blocked request."
-
-Finally, open the app at:
-
-```text
-https://dbpdba.seliseblocks.com:5173
-```
-
-**Not** `http://`, **not** `localhost` — either one skips the cookie entirely even though the app loads.
-
-## Trusting the cert (optional but recommended)
-
-The cert is self-signed, so the browser shows a one-time warning until trusted. `npm run cert` prints the exact trust command for your OS when it finishes:
-
-- Windows (elevated prompt): `certutil -addstore -f Root .cert\dev-cert.pem`
-- macOS: `sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain .cert/dev-cert.pem`
-- Linux: `sudo cp .cert/dev-cert.pem /usr/local/share/ca-certificates/blocks-dev.crt && sudo update-ca-certificates`
-
-Restart the browser after trusting so it picks up the new trust store entry. `.cert/` is already gitignored by the scaffold — it's per-machine, never committed.
-
-## Still need a public OIDC client
-
-Local HTTPS alone doesn't make login succeed if no OIDC client is registered yet, or if its `redirect_uris` don't include this exact dev origin. That registration is portal-only (see blocks-onboarding's Gotchas) — out of scope here, but it's the next thing to check if HTTPS is right and login still fails. The redirect URI must match byte-for-byte, including `:5173`.
-
-## Gotchas
-
-**Custom app domain: the API base URL must share its registrable domain, or the cookie never lands.** `blocks new web --app-domain` isn't limited to `*.seliseblocks.com` — it also supports custom domains (e.g. `abc.slsblx.com`, `xyz.blx10.com`). On a custom domain, the hosted-login session cookie is only stored by the browser if `VITE_BLOCKS_API_URL` shares the app's registrable domain. Concretely:
-
-- `abc.slsblx.com` → `VITE_BLOCKS_API_URL` must be `https://blocksapi.slsblx.com`
-- `xyz.blx10.com` → `VITE_BLOCKS_API_URL` must be `https://blocksapi.blx10.com`
-
-If `VITE_BLOCKS_API_URL` is left at the default `https://api.seliseblocks.com` while the app itself runs on a custom domain, the browser treats the API as cross-site relative to the app and never stores the cookie — login still redirects back and *looks* successful, but cookie-based calls (`/iam/me`, organization switching, logout) silently fail. Check `VITE_BLOCKS_API_URL` in `.env` first whenever the app domain is not `*.seliseblocks.com` and auth-dependent calls are failing despite HTTPS and the cert being set up correctly.
-
-## Troubleshooting
-
-| Symptom | Likely cause | Fix |
-|---|---|---|
-| Login redirects back but app shows logged-out | Opened on `http://` or `localhost` instead of the HTTPS dev host | Check the URL bar: must be `https://<VITE_BLOCKS_DEV_HOST>:5173` exactly |
-| Browser "not private" warning | Self-signed cert not trusted yet | Run the OS trust command `npm run cert` printed, then restart the browser |
-| Vite: "Blocked request. This host is not allowed" | `allowedHosts` doesn't include the host being requested — usually `.env`'s `VITE_BLOCKS_DEV_HOST` was edited/missing after scaffold, or the browser is hitting a different hostname than expected | Confirm `.env` has the right `VITE_BLOCKS_DEV_HOST` and that the URL bar matches it exactly |
-| Page doesn't load at all / DNS error | Hosts file entry missing or wrong | Add `127.0.0.1 <VITE_BLOCKS_DEV_HOST>` to `C:\Windows\System32\drivers\etc\hosts` (as Administrator) |
-| `npm run cert` errors "No domain given" | `.env` missing or `VITE_BLOCKS_DEV_HOST` not set | Confirm `.env` exists with `VITE_BLOCKS_DEV_HOST=<host>`, or run `npm run cert -- <domain>` explicitly |
-| `npm run dev` fails to bind the port | Port 5173 already in use (dev server uses `strictPort`, won't fall back) | Free port 5173, or the port is fixed because it's part of the registered OIDC redirect URI — don't just change it without updating the OIDC client too |
-| HTTPS works, cert trusted, login still fails | No OIDC client registered yet, or its redirect URI doesn't match this origin exactly | Register/update the public OIDC client in the portal with `https://<VITE_BLOCKS_DEV_HOST>:5173/login/callback` as a redirect URI (portal-only, see blocks-onboarding) |
-| Works for one dev, fails for a teammate | Each machine needs its own cert + hosts entry — `.cert/` is gitignored on purpose | Teammate runs `npm run cert` and adds the hosts entry on their own machine |
-
-## Example trigger prompts
-
-- "Run my app locally over HTTPS on its real domain so SSO works"
-- "My local login isn't working — it just bounces back to the login page"
-- "How do I set up the dev cert for this scaffolded app?"
-- "I'm getting 'Blocked request. This host is not allowed' from Vite"
-- "Do I need OpenSSL to run npm run cert on Windows?"
-- "Why does login work in production but not on localhost?"

package/dist/skills/blocks-iam-access-control/SKILL.md

@@ -1,49 +0,0 @@
----
-name: blocks-iam-access-control
-description: "Work with SELISE Blocks RBAC (roles & permissions) via `blocks iam roles/permissions *` (CLI, project-scoped) or `blocksClient.iam.*` (SDK), never raw fetch/curl. Two facets: read-only feature-gating by the current user's own roles/permissions (common, safe) vs. creating/editing role and permission definitions (sensitive, human-confirmed only — CLI `--dry-run`→`--yes` or an in-app admin screen). OIDC/identity-provider provisioning stays portal-only, a different concern. Use for permission-gated UI, role/permission pickers, or building/scripting role & permission admin ('gate this button by permission', 'create a role and grant permissions', 'list permissions by severity')."
----
-
-# Blocks IAM — Access Control (Permissions & Roles)
-
-This skill covers **permission and role definitions** in SELISE Blocks — the RBAC model itself, not who has which role (that's the blocks-iam-users skill). Everything goes through either `blocks iam roles/permissions *` (CLI) or `blocksClient.iam.*` from **`@seliseblocks/client`**, the single SDK instance every `blocks new web` scaffold wires up at `src/lib/blocks/client.ts` and exports as `blocksClient`. No raw `fetch`/`curl` for either surface.
-
-```ts
-import { blocksClient } from "../../lib/blocks/client";
-```
-
-## The platform boundary — read this before writing any code
-
-Role and permission administration is **not** portal-only or app-UI-only — `blocks` has a full, working CLI surface for it too. There are two equally real surfaces for the same operations, and the choice is about *where the human is*, not which one is "allowed" — see [flows/manage-roles-permissions.md](flows/manage-roles-permissions.md) for the full command reference and the CLI-vs-SDK decision.
-
-Identity-provider/OIDC client provisioning is the one piece that really is **portal-only, human-driven**, at `https://os.seliseblocks.com` — unrelated to roles/permissions, don't bolt it onto this skill.
-
-Keep the two facets below (read-only feature-gating vs. sensitive admin mutations) separate in your head (and in your code) — they have very different risk profiles regardless of which surface (CLI or SDK) you're using.
-
-## Facet 1 — Feature-gating a frontend by the user's own permissions (common, low risk)
-
-Read-only, scoped to whoever is signed in, needs no special confirmation. `useCurrentUser()` + `iam.resources.features()` + `iam.roles.assignable()`.
-
-→ Full walkthrough: [flows/feature-gating.md](flows/feature-gating.md)
-
-## Facet 2 — Creating/editing roles & permissions (sensitive)
-
-Legitimate only in direct response to a human's explicit, in-the-moment instruction — CLI (`--dry-run` reviewed, then `--yes`) or a signed-in admin's own in-app screen. Never something an agent decides to invoke on its own initiative.
-
-→ Full command reference, SDK methods, and confirm-before-mutating pattern: [flows/manage-roles-permissions.md](flows/manage-roles-permissions.md)
-
-## Gotchas
-
-- **CLI mutations are project-scoped, not account-scoped** — they run against the impersonated-project token; `blocks iam me` is the one IAM command that uses the account token instead.
-- **Role hierarchy and permission assignment key off `slug`**, not `itemId`.
-- **Never fire a create/update/assign-permissions call — CLI or SDK — without a human confirming that specific change first.** See [flows/manage-roles-permissions.md](flows/manage-roles-permissions.md) for the full discipline.
-- **OIDC/identity-provider client provisioning is always portal-only**, independent of everything above.
-
-## Example trigger prompts
-
-- "Only show the delete button to users who have the `order::delete` permission." → Facet 1
-- "Hide this whole admin section unless the signed-in user has an admin role." → Facet 1
-- "What roles am I allowed to assign to other users?" → Facet 1
-- "Show me permissions grouped by severity in a settings panel." → Facet 1
-- "Build an admin page where I can create a role and pick which permissions it gets." → Facet 2
-- "Create a `content-editor` role from the CLI with these permissions." → Facet 2
-- "Can you just set up a few default roles for my project?" → confirm the exact list with the human first (in chat, or via a reviewed `--dry-run`), then run each `blocks iam roles create`/`assign-permissions` with `--yes` only after they say go — don't auto-provision without that per-change confirmation.

package/dist/skills/blocks-iam-access-control/flows/feature-gating.md

@@ -1,38 +0,0 @@
-# Flow: Feature-gating a frontend by the user's own permissions (common, low risk)
-
-This is read-only against IAM and scoped to whoever is signed in, so it needs no special confirmation — build it the same way you'd build any other data-fetching feature.
-
-The scaffold already gives you a `useCurrentUser()` hook (`src/features/profile/useCurrentUser.ts`) wrapping `blocksClient.iam.me()` with TanStack Query; `me()` returns `{ data: { itemId, email, firstName, lastName, roles: string[], permissions: string[], ... } }`. Reuse it instead of re-fetching:
-
-```ts
-// src/features/access/usePermission.ts
-import { useCurrentUser } from "../profile/useCurrentUser";
-
-export function useHasPermission(permission: string): boolean {
-  const me = useCurrentUser();
-  return me.data?.data?.permissions?.includes(permission) ?? false;
-}
-
-export function useHasRole(role: string): boolean {
-  const me = useCurrentUser();
-  return me.data?.data?.roles?.includes(role) ?? false;
-}
-```
-
-```tsx
-// src/shared/ui/RequirePermission.tsx
-import type { ReactNode } from "react";
-import { useHasPermission } from "../../features/access/usePermission";
-
-export function RequirePermission({ permission, children }: { permission: string; children: ReactNode }) {
-  if (!useHasPermission(permission)) return null;
-  return <>{children}</>;
-}
-```
-
-Two more read methods round this out:
-
-- `blocksClient.iam.resources.features(query?)` — feature/resource flags for the active user context; use this to drive nav items or feature flags that are more granular than a flat permission string.
-- `blocksClient.iam.roles.assignable()` — lists roles the **current caller** is allowed to assign. If you're building a "grant this user a role" picker, populate it from `assignable()`, not from `roles.list()` — don't assume every role in the system is one this particular admin may hand out.
-
-There is also a CLI read path for the same data, useful outside an app (scripting/inspection): `blocks iam roles list/get/assignable` and `blocks iam permissions list/get/by-severity` — see [manage-roles-permissions.md](manage-roles-permissions.md) for the full CLI command reference (it covers both reads and mutations).