@semacode/cli 2.3.1 → 3.0.0

package/docs/profiles.md

@@ -1,54 +1,54 @@
-# Profiles
-
-Profiles are local validation layers for domains where syntax alone is not
-enough. They use the same `.sema` DSL and do not create a second language.
-
-## Principle
-
-A profile checks whether a contract is strong enough for a specific kind of
-work. It can require:
-
-- contract-first workflow;
-- domain core fields;
-- required rules, effects, guarantees, and tests;
-- explicit forbidden behavior;
-- evidence before closing the change.
-
-When a profile returns `bloqueado: true`, the artifact is not approved.
-
-## Commands
-
-```bash
-sema profile capabilities --json
-sema profile validar software contratos/example.sema --maturidade production --preset default --json
-sema profile validar simulation contratos/example.sema --maturidade production --preset calibration --json
-sema rule-packs --profile software --json
-```
-
-## Built-In Profiles
-
-- `software`: code, APIs, modules, refactors, persistence, and generated output.
-- `workflow`: automations, queues, webhooks, scheduled jobs, and orchestration.
-- `ops`: deploy plans, rollback, incidents, runbooks, and operational evidence.
-- `legal`: terms, privacy, compliance, risk, and regulated language.
-- `research`: comparisons, uncertainty, evidence, citations, and decisions.
-- `game`: rules, loops, player states, scoring, and playability checks.
-- `simulation`: models, assumptions, units, scenarios, calibration, uncertainty,
-  deterministic replay, and tolerance evidence.
-- `redacao`: editorial and creative writing, narrative structure, voice,
-  clarity, and publication-ready evidence.
-- `propostas`: commercial proposals, scope clarity, deliverables, constraints,
-  and client-ready wording.
-- `conversas`: customer conversation guardrails, escalation, pricing promises,
-  and channel changes.
-
-Profiles are local CLI checks. They do not create or require external service
-accounts.
-
-`author` remains a dedicated workflow under `sema author`; it is not exposed as
-a fake `sema profile validar author` gate. Use `sema descobrir explicar workflow.author`
-to inspect that boundary.
-
-The legacy `sema profile capabilities` view lists only profiles accepted by
-`profile validar`; its separate `workflowsEspecializados` field points Author
-to `sema author` without advertising an invalid validation command.
+# Profiles
+
+Profiles are local validation layers for domains where syntax alone is not
+enough. They use the same `.sema` DSL and do not create a second language.
+
+## Principle
+
+A profile checks whether a contract is strong enough for a specific kind of
+work. It can require:
+
+- contract-first workflow;
+- domain core fields;
+- required rules, effects, guarantees, and tests;
+- explicit forbidden behavior;
+- evidence before closing the change.
+
+When a profile returns `bloqueado: true`, the artifact is not approved.
+
+## Commands
+
+```bash
+sema profile capabilities --json
+sema profile validar software contratos/example.sema --maturidade production --preset default --json
+sema profile validar simulation contratos/example.sema --maturidade production --preset calibration --json
+sema rule-packs --profile software --json
+```
+
+## Built-In Profiles
+
+- `software`: code, APIs, modules, refactors, persistence, and generated output.
+- `workflow`: automations, queues, webhooks, scheduled jobs, and orchestration.
+- `ops`: deploy plans, rollback, incidents, runbooks, and operational evidence.
+- `legal`: terms, privacy, compliance, risk, and regulated language.
+- `research`: comparisons, uncertainty, evidence, citations, and decisions.
+- `game`: rules, loops, player states, scoring, and playability checks.
+- `simulation`: models, assumptions, units, scenarios, calibration, uncertainty,
+  deterministic replay, and tolerance evidence.
+- `redacao`: editorial and creative writing, narrative structure, voice,
+  clarity, and publication-ready evidence.
+- `propostas`: commercial proposals, scope clarity, deliverables, constraints,
+  and client-ready wording.
+- `conversas`: customer conversation guardrails, escalation, pricing promises,
+  and channel changes.
+
+Profiles are local CLI checks. They do not create or require external service
+accounts.
+
+`author` remains a dedicated workflow under `sema author`; it is not exposed as
+a fake `sema profile validar author` gate. Use `sema descobrir explicar workflow.author`
+to inspect that boundary.
+
+The legacy `sema profile capabilities` view lists only profiles accepted by
+`profile validar`; its separate `workflowsEspecializados` field points Author
+to `sema author` without advertising an invalid validation command.

package/docs/repositories.md

@@ -15,7 +15,8 @@ and English documentation.
 - local package scripts
 - `AGENTS.md` as the official Codex entrypoint
 - the official Sema skill as a thin bootstrap before `AGENTS.md` exists
-- the repo marketplace that installs that skill explicitly
+- the managed absolute launcher and portable global skill bundled in npm
+- the optional repo marketplace that exposes the same skill namespaced
 
 ## Not Public
 
@@ -23,10 +24,26 @@ and English documentation.
 - real credentials, environment files, or secret inventories
 - private project data or generated private artifacts
 - runtime authorization, activation, billing, credit, token, or panel gates
-- product-specific entrypoint files for AI clients other than Codex
+- product-specific repository entrypoint files for AI clients other than Codex
 - MCP servers, remote workspace bridges, or duplicated governance inside the
   bootstrap skill
 
+The portable skill may be synchronized to the canonical user-level
+`.agents/skills` directory and a detected Claude mirror. That does not change
+the workspace boundary: Sema still generates only `AGENTS.md` as the official
+repository protocol and never writes into plugin caches.
+
+The repository has one npm package factory: `npm run cli:empacotar-publica`.
+It assembles a private stage per execution and never materializes examples,
+runtime dependencies, or skills inside `pacotes/cli`. Direct workspace packing
+is intentionally blocked so a second, mutable packaging path cannot drift from
+the public artifact.
+
+The Windows distribution uses `sema.ps1` for PowerShell `PATH` resolution,
+`sema.cmd` for `cmd.exe`, and `sema-managed.ps1` for the PATH-independent
+fallback invoked through the absolute system `powershell.exe`; all remain
+inside the managed `~/.sema/bin` boundary.
+
 The CLI must run directly against the local workspace without login, user
 authorization, a product-license check, activation key, credits, token, billing
 service, or control panel.

package/docs/rollback.md

@@ -1,7 +1,7 @@
 # Rollback Boundary
 
-Public rollback covers both the npm CLI and the separately installed Codex
-bootstrap skill.
+Public rollback covers the npm CLI, managed launcher, bundled global skill, and
+the optional Codex plugin channel.
 
 For a failed pre-publication candidate:
 
@@ -11,16 +11,23 @@ For a failed pre-publication candidate:
 3. Re-run `npm run release:preparar-publica`.
 
 If a bad commit was already pushed, revert it with a normal Git revert and push
-the corrective commit. Refresh the marketplace and reinstall the skill:
+the corrective commit. Install the corrected npm version and resynchronize its
+managed distribution:
 
 ```bash
-codex plugin marketplace upgrade sema
-codex plugin remove sema@sema
-codex plugin add sema@sema
+npm install -g @semacode/cli@<corrected-version>
+sema skill sync --json
 ```
 
-Open a new Codex task before validating the reinstalled skill. Already-open
-tasks keep the plugin/skill catalog they started with.
+The same sequence may install an explicitly selected previous version. The
+installed npm version is authoritative: `sema skill sync --json` aligns the
+runtime, managed launcher, and bundled skill to the version that is actually
+installed. This is synchronization, not a promise to block an intentional
+downgrade.
+
+If the optional plugin channel was also affected, upgrade or reinstall it after
+the corrected commit is public. Open a new task before validating the repaired
+skill; already-open tasks keep the catalog they started with.
 
 If a bad npm version was published, do not overwrite it. Publish a corrected
 version and direct users to that version. Verify the final registry/GitHub state

package/docs/security.md

@@ -7,9 +7,31 @@ Local Sema execution does not need a credential, login, activation key, license
 token, billing token, or control-panel session. Do not introduce one as a
 condition for reading or governing a local workspace.
 
-The official Codex bootstrap skill contains instructions only. It must not
-bundle an MCP server, app connector, remote workspace bridge, credential flow,
-or a second copy of the repository governance that belongs in `AGENTS.md`.
+The official bootstrap skill contains instructions only. The global npm
+postinstall may atomically update the managed launcher under `~/.sema/bin`, the
+canonical copy under `~/.agents/skills/sema`, and a Claude mirror under
+`~/.claude/skills/sema` when Claude is already detected. It must not scan the
+home recursively, overwrite an unowned destination, follow symlinks or
+junctions, write into a plugin cache, bundle an MCP server, add a credential
+flow, or duplicate the repository governance that belongs in `AGENTS.md`.
+
+Status output exposes symbolic paths such as `$HOME/.sema/bin/sema`,
+`$HOME/.sema/bin/sema.ps1`, `$HOME/.sema/bin/sema.cmd`, and
+`$HOME/.sema/bin/sema-managed.ps1`, never the real home, Node.js executable, or
+package path. On Windows, PowerShell resolves `sema.ps1` from `PATH`, `cmd.exe`
+resolves `sema.cmd`, and the fallback runs `sema-managed.ps1` through
+`%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe`. A managed receipt
+detects isolated corruption of the launchers and companion; it is integrity
+recovery, not authentication against a hostile process running as the same
+user. Private absolute paths are not published in JSON or logs.
+
+The public-package factory rejects pre-existing symlinks, junctions, and
+reparse points in source, stage, and output chains and revalidates filesystem
+identity around each path-based operation. This is fail-closed hardening, not a
+native sandbox: Node.js does not expose cross-platform `openat`/`linkat`-style
+operations anchored to directory handles, so a hostile process running as the
+same operating-system user can still race a parent-path swap. Do not present
+the private package stage as a security boundary against that attacker.
 
 Do not publish: