@lotagate/cli 0.1.24 → 0.1.26

package/scripts/install-native.mjs

@@ -10,8 +10,11 @@ const target = targetForRuntime(process.platform, process.arch);
 
 if (existsSync(resolve(packageRoot, '.git'))) process.exit(0);
 
-if (target === undefined) await installNodeFallback();
-else await installNativeTarget(target);
+if (target === undefined) {
+  if (process.platform === 'win32' || process.platform === 'cygwin') fail(`No native LotaGate CLI artifact is available for ${process.platform}/${process.arch}.`);
+} else {
+  await installNativeTarget(target);
+}
 
 function findInstalledNativePackageRoot(packageName) {
   const segments = packageName.split('/');
@@ -45,17 +48,6 @@ async function installNativeTarget(nativeTarget) {
   }
 }
 
-async function installNodeFallback() {
-  if (process.platform === 'win32' || process.platform === 'cygwin') fail(`No native LotaGate CLI artifact is available for ${process.platform}/${process.arch}.`);
-  const destination = resolve(packageRoot, 'bin', 'lotagate.exe');
-  try {
-    await installExecutable(resolve(packageRoot, 'bin', 'lotagate.mjs'), destination);
-  } catch (error) {
-    await rm(destination, { force: true }).catch(() => undefined);
-    fail(`Node launcher installation failed: ${error instanceof Error ? error.message : String(error)}`);
-  }
-}
-
 async function installExecutable(source, destination) {
   const temporary = `${destination}.install-${process.pid}-${Date.now()}`;
   await mkdir(dirname(destination), { recursive: true });

package/skills/architecture-review/SKILL.md

@@ -1,22 +1,49 @@
 ---
 name: architecture-review
-description: Trace a feature end to end and assess ownership, boundaries and extensibility.
-user-invocable: true
-model-invocable: true
+description: Trace a feature or subsystem end to end and assess ownership, dependency boundaries, contracts, risks and extensibility before implementation.
 allowed-tools: [filesystem.read, filesystem.list]
 ---
 # Architecture review
 
-Analyze the requested feature using evidence from the repository.
+Assess the requested feature or subsystem using repository evidence before
+implementation. This skill produces an architecture decision, not a rewrite.
 
-1. Identify the entry point, owning module and allowed dependency direction.
-2. Trace the flow through validation, application logic, ports, infrastructure
-   adapters and presentation boundaries.
-3. Reuse existing abstractions before proposing new files or dependencies.
-4. Check for duplicated business rules, leaky infrastructure details and
-   unclear ownership.
-5. Propose the smallest complete design that preserves contracts and supports
-   testing, operations and future extension; do not defer required behavior.
+## Trace the current system
 
-Clearly distinguish confirmed facts from recommendations and runtime
-verification requirements.
+1. Read applicable guidance, package boundaries, entry points, manifests,
+   configuration and tests.
+2. Map the real flow:
+   `entry point -> validation -> authorization/trust -> application/domain ->
+   port -> infrastructure adapter -> persistence/external service -> mapper ->
+   response/rendering`.
+3. Identify the owner of each rule, allowed dependency direction, public
+   contract, runtime schema, lifecycle and failure boundary.
+4. Search for existing components, services, repositories, clients, policies,
+   constants, error types and test helpers before proposing new abstractions.
+5. Note duplicated rules, circular dependencies, leaky infrastructure types,
+   UI-owned authorization, hidden side effects and unclear transaction or
+   resource boundaries.
+
+## Evaluate the requested design
+
+Assess:
+
+- business behavior and contract preservation;
+- authentication, authorization, project trust and tenant/resource ownership;
+- validation, error semantics, observability and operational support;
+- cancellation, timeout, retries, bounded concurrency and cleanup;
+- persistence, cache consistency and migration/rollback needs;
+- test boundaries and realistic failure/empty states;
+- future extension cost without premature generic abstraction.
+
+Compare the smallest complete option with viable alternatives. Recommend a new
+file, dependency or layer only when the existing owner cannot support the
+behavior cleanly. Do not defer required correctness or hide a migration risk.
+
+## Report
+
+Separate confirmed repository facts, inferred risks, recommendations and items
+requiring runtime verification. Include the affected flow, ownership map,
+contract impact, proposed module boundaries, reuse decisions, alternatives,
+trade-offs, change risk and a staged verification plan. Do not modify files
+unless the user explicitly requests implementation.

package/skills/code-review/SKILL.md

@@ -1,20 +1,49 @@
 ---
 name: code-review
-description: Review a change for correctness, security, maintainability and regression risk.
-user-invocable: true
-model-invocable: true
+description: Review an implementation or diff for correctness, security, architecture, maintainability and regression risk with evidence-backed findings.
 allowed-tools: [filesystem.read, filesystem.list]
 ---
 # Code review
 
-Review the requested repository scope as a production code review.
+Review the requested scope as a production change. This is an audit skill:
+do not edit files unless the user explicitly asks to implement a finding.
 
-1. Trace the affected execution flow before forming conclusions.
-2. Inspect the relevant callers, callees, contracts, validation and tests.
-3. Report confirmed defects before style preferences.
-4. For every finding, include severity, confidence, file/location, evidence,
-   impact and a focused remediation.
-5. Check security boundaries, error paths, cancellation, resource cleanup and
-   regression coverage.
+## Review procedure
 
-Do not modify files unless the user explicitly asks for implementation.
+1. Read applicable guidance and inspect the complete diff, not only the changed
+   lines. Identify generated or unrelated changes.
+2. Trace each changed path from entry point through validation, authorization,
+   business logic, persistence/external adapters and user-visible output.
+3. Inspect callers, callees, DTOs/types, runtime schemas, configuration,
+   migrations, error handling, logging, tests and deployment assumptions.
+4. Check correctness and data integrity first, then security, reliability,
+   concurrency, resource cleanup, maintainability and performance.
+5. Exercise the reasoning against empty, malformed, duplicate, concurrent,
+   cancelled, timed-out, unauthorized and partially failed cases.
+6. Prefer confirmed defects over style preferences. Do not infer a bug from a
+   name or estimate performance without measurements.
+
+## Required finding format
+
+For every actionable finding, report:
+
+- stable ID and category;
+- severity: Critical, High, Medium or Low;
+- confidence: Confirmed, High Confidence, Medium Confidence or Needs Verification;
+- file and exact symbol/location;
+- affected flow and trigger condition;
+- problem, repository evidence, root cause and concrete impact;
+- smallest safe recommendation and existing pattern to follow;
+- alternatives/trade-offs, change risk and verification method.
+
+Group symptoms with the same root cause. State explicitly when a behavior is
+correct, when an issue is only a design trade-off, and when runtime/load
+verification is still required. Never expose secrets or reproduce sensitive
+payloads in findings.
+
+## Review conclusion
+
+Summarize coverage and limitations, finding count and severity distribution,
+highest-risk issues, systemic causes, quick wins and unverified items. If the
+user requests implementation afterward, convert only confirmed findings into a
+focused patch and preserve the review evidence.

package/skills/debugging/SKILL.md

@@ -1,20 +1,57 @@
 ---
 name: debugging
-description: Diagnose a reproducible failure from evidence and prepare a minimal safe fix.
-user-invocable: true
-model-invocable: true
+description: Diagnose a reproducible software failure from repository and runtime evidence, then implement a minimal verified fix when requested.
 allowed-tools: [filesystem.read, filesystem.list, shell.exec]
 ---
 # Debugging
 
-Diagnose the reported failure without guessing.
+Find the root cause of the reported failure without guessing or masking the
+symptom. If the user asks for diagnosis only, do not modify source files.
 
-1. Reproduce or isolate the failure with the narrowest safe command.
-2. Trace the input from its boundary to the failing operation.
-3. Compare the runtime behavior with the declared types, validation and
-   configuration.
-4. Identify the root cause, affected cases and regression risk.
-5. Add or update a focused regression test before implementing a fix.
-6. Run the narrow test first, then the relevant project checks.
+## Establish evidence
 
-Do not hide failures, weaken validation or modify unrelated modules.
+1. Read applicable repository guidance and inspect the current diff before
+   changing anything.
+2. Capture the exact trigger, input shape, environment, command, expected
+   result and observed result. Keep credentials and sensitive payloads out of
+   notes and logs.
+3. Reproduce with the narrowest safe test or command. If reproduction is not
+   possible, state `Needs runtime verification` and isolate the closest
+   deterministic boundary instead of inventing behavior.
+4. Search callers and callees, then trace the value through parsing,
+   validation, state transitions, persistence, external adapters and rendering.
+5. Compare implementation behavior with types, schemas, configuration,
+   authorization/trust rules and documented contracts.
+
+## Classify the cause
+
+Separate:
+
+- confirmed root cause;
+- contributing condition;
+- affected and unaffected cases;
+- data-integrity, security, concurrency or resource-lifecycle risk;
+- pre-existing failure or environment limitation.
+
+Check malformed input, empty state, retries, timeout/cancellation, concurrent
+requests, stale UI responses, permission denial, partial writes and cleanup.
+Do not call a style preference a bug and do not claim a security issue without
+tracing user-controlled data to the sensitive sink.
+
+## Fix only when authorized
+
+When implementation is requested:
+
+1. Add a focused regression test that fails for the reported behavior and
+   protects the business invariant.
+2. Apply the smallest fix in the module that owns the behavior. Reuse existing
+   validators, error contracts, state machines and utilities.
+3. Preserve unrelated behavior, public contracts, authorization and
+   observability. Do not weaken validation, broaden permissions or swallow
+   exceptions to make the test pass.
+4. Run the focused test first, then typecheck/lint/build and the relevant
+   integration or regression suite.
+
+Report the trigger, evidence, root cause, fix, tests and any remaining runtime
+verification. Never report a reproduction or test as successful unless it was
+actually run.

package/skills/documentation/SKILL.md

@@ -1,16 +1,50 @@
 ---
 name: documentation
-description: Produce accurate maintainable documentation from verified repository behavior.
-user-invocable: true
-model-invocable: true
+description: Produce and maintain accurate engineering documentation from verified repository behavior, contracts and operational workflows.
 allowed-tools: [filesystem.read, filesystem.list, filesystem.write]
 ---
 # Documentation
 
-Inspect the implementation, configuration and existing documentation before
-writing. Document the supported workflow, prerequisites, configuration,
-security boundaries, failure behavior, examples and verification commands.
+Create documentation that helps its intended reader make the correct decision
+or complete the supported workflow. Documentation is part of the product
+contract: never document an assumption as a feature.
 
-Keep documentation aligned with public behavior, avoid secrets and speculative
-claims, preserve the project voice, and update the nearest authoritative file
-rather than creating duplicate guidance.
+## Discover the source of truth
+
+1. Read applicable guidance, the nearest README/design document, package
+   metadata and the complete implementation path.
+2. Verify public commands, routes, IPC/API payloads, configuration keys,
+   defaults, scopes, permissions, error behavior, lifecycle and supported
+   platforms from code, schemas and tests.
+3. Search for existing documentation and update the nearest authoritative
+   source. Do not create duplicate instructions or conflicting quick starts.
+4. Identify the audience and task: user guide, API reference, architecture
+   decision, operations runbook, troubleshooting guide or changelog.
+
+## Write the useful contract
+
+Include only verified and task-relevant information:
+
+- purpose, scope and explicit non-goals;
+- prerequisites, installation and configuration;
+- normal workflow with copyable, safe examples;
+- inputs, outputs, defaults, limits, scopes and permissions;
+- loading, empty, error, timeout, cancellation and recovery behavior;
+- security boundaries, trust requirements and sensitive-data rules;
+- compatibility, platform limitations, migrations and rollback;
+- documented verification commands and expected outcomes.
+
+Use the project voice and stable terminology. Keep titles specific, put the
+most important behavior first, avoid unsupported promises and never include
+credentials, private paths, raw tokens or unbounded sensitive payloads.
+
+## Validate before handoff
+
+Cross-check examples against command catalogs, types and schemas. Run the
+narrowest relevant documentation/example test or validation command when one
+exists. Re-read links, code snippets, paths, version values and negative cases.
+If implementation evidence is incomplete, label the statement `Needs
+Verification` instead of guessing.
+
+Report the authoritative files updated, verified sources, commands run, known
+limitations and any remaining documentation drift risk.

package/skills/feature-implementation/SKILL.md

@@ -1,25 +1,64 @@
 ---
 name: feature-implementation
-description: Implement a requested feature end to end while preserving architecture, contracts and operational safety.
-user-invocable: true
-model-invocable: true
+description: Implement an explicitly requested product or engineering feature end to end while preserving architecture, contracts, security and operational safety.
 allowed-tools: [filesystem.read, filesystem.list, filesystem.exists, filesystem.write, shell.exec]
 ---
 # Feature implementation
 
-Implement only an explicitly requested behavior change.
-
-1. Read repository guidance, the package manifest, relevant configuration and
-   the complete affected flow before editing.
-2. Identify the owning layer, reusable abstractions, public contracts and
-   trust boundaries. Extend an existing abstraction when ownership remains
-   cohesive.
-3. Define the smallest complete design, including validation, errors,
-   cancellation, persistence and user-visible states where applicable.
-4. Edit cohesive files with complete content. Preserve unrelated changes and
-   never write secrets, generated artifacts or unrelated formatting.
-5. Run focused type, lint and behavior checks after the implementation, then
-   run the relevant integrated regression checks.
-6. Report changed files, preserved contracts, evidence, limitations and risks.
-
-Do not defer required behavior or claim completion without verification.
+Deliver the explicitly requested behavior as a complete, reviewable change.
+Do not silently broaden the product scope, redesign an unrelated subsystem, or
+turn a one-off example into a new platform abstraction.
+
+## Before editing
+
+1. Read the applicable `AGENTS.md`, package manifest, README, architecture
+   notes, build configuration, test configuration and environment examples.
+2. Inspect the current working tree and preserve unrelated user changes.
+3. Trace the affected flow end to end:
+   - UI: route -> page -> components -> state/hooks -> API/IPC -> response -> render.
+   - Backend/CLI: command or route -> validation -> application service -> port -> adapter -> persistence/external system -> response.
+4. Identify the owning module, dependency direction, public contracts, runtime
+   schemas, authorization/trust boundary and existing reusable abstractions.
+5. Search for equivalent components, services, validators, mappers, constants,
+   error types and test utilities before creating anything new.
+
+## Design the smallest complete change
+
+Define the behavior before implementation:
+
+- normal, loading, empty, malformed-input and failure states;
+- validation at every trust boundary and stable error semantics;
+- authorization, project trust, scope and approval behavior;
+- cancellation, timeout, retry and resource cleanup where I/O is involved;
+- persistence, cache invalidation, ordering and concurrency behavior;
+- accessibility and user-visible feedback for UI changes;
+- migration, compatibility and rollback implications when a contract changes.
+
+Keep business rules in their owning domain/application layer. Keep controllers,
+IPC handlers and UI components as orchestration boundaries rather than sources
+of truth. Prefer extending a cohesive existing abstraction over duplicating a
+rule or introducing a generic shared helper with unclear ownership.
+
+## Implement incrementally
+
+1. Make the smallest cohesive edit and keep the diff focused.
+2. Preserve existing inputs, outputs, error codes, side effects and ordering
+   unless the request explicitly changes them.
+3. Use runtime validation for external data even when TypeScript types exist.
+4. Bound concurrency, payload size, recursion, retries and memory where the
+   feature can process user-controlled or remote data.
+5. Never log credentials, tokens, raw secrets, unbounded tool input or sensitive
+   file contents. Do not edit generated files or lockfiles without a reason.
+6. Add focused tests for business invariants, failure paths and authorization
+   boundaries before combining broader changes.
+
+## Verify and hand off
+
+Run the narrowest documented typecheck, lint, unit or integration test after
+each safe unit, then run the relevant package build and regression checks. If a
+check fails, report the exact command and distinguish an introduced failure
+from a pre-existing or environment failure; never hide it.
+
+The final report must state what changed, why, files touched, contracts and
+business behavior preserved or intentionally changed, commands and results,
+known limitations, remaining risks and any manual runtime verification needed.

package/bin/lotagate.exe

@@ -1 +0,0 @@
-Native executable installation did not complete. Reinstall @lotagate/cli without --ignore-scripts or --omit=optional.

package/skills/api-contract-review/SKILL.md

@@ -1,17 +0,0 @@
----
-name: api-contract-review
-description: Review an API contract, adapter or protocol flow for compatibility, validation and failure behavior.
-user-invocable: true
-model-invocable: true
-allowed-tools: [filesystem.read, filesystem.list]
----
-# API contract review
-
-Trace the request and response from the public boundary through validation,
-application logic, adapters and mapping.
-
-Check input and output schemas, optionality, backward compatibility, error
-codes, authentication, authorization, timeouts, retries, cancellation,
-pagination, idempotency and sensitive data exposure. Compare the contract with
-callers and tests. Report evidence-backed findings and distinguish runtime
-verification requirements from confirmed behavior.

package/skills/database-review/SKILL.md

@@ -1,17 +0,0 @@
----
-name: database-review
-description: Review database access for correctness, integrity, query behavior and concurrency safety.
-user-invocable: true
-model-invocable: true
-allowed-tools: [filesystem.read, filesystem.list]
----
-# Database review
-
-Trace repositories, queries, transactions and constraints through their
-callers. Inspect filtering, tenant isolation, soft deletion, pagination,
-indexes, joins, read-modify-write races, unique constraints, lock behavior and
-external calls inside transactions.
-
-Do not recommend an index or schema change without query shape, data-volume and
-write-amplification evidence. Label runtime plans and load behavior as needing
-verification when no measurements are available.

package/skills/dependency-review/SKILL.md

@@ -1,16 +0,0 @@
----
-name: dependency-review
-description: Evaluate a dependency change for necessity, security, compatibility and operational cost.
-user-invocable: true
-model-invocable: true
-allowed-tools: [filesystem.read, filesystem.list, shell.exec]
----
-# Dependency review
-
-Check whether an existing abstraction, direct dependency, native API or
-framework capability already solves the problem. If a new package is still
-justified, assess maintenance, license, advisories, transitive dependencies,
-runtime cost, compatibility, migration risk and rollback.
-
-Do not modify manifests or lockfiles unless the user explicitly requests the
-dependency change and the evidence supports it.

package/skills/frontend-review/SKILL.md

@@ -1,18 +0,0 @@
----
-name: frontend-review
-description: Review a frontend flow for state ownership, rendering behavior, accessibility and resilient user states.
-user-invocable: true
-model-invocable: true
-allowed-tools: [filesystem.read, filesystem.list]
----
-# Frontend review
-
-Trace route, page, component, state, request and render behavior. Check state
-ownership, derived state, effect chains, stale responses, cancellation,
-loading/error/empty states, keyboard access, focus, semantics, large lists and
-user-visible failure recovery.
-
-Recommend memoization or component extraction only when the affected subtree,
-trigger and measurable benefit are clear. Preserve the established frontend
-architecture and avoid presentation code becoming the source of truth for
-authorization.

package/skills/incident-response/SKILL.md

@@ -1,18 +0,0 @@
----
-name: incident-response
-description: Investigate an operational failure using a bounded evidence-first response workflow.
-user-invocable: true
-model-invocable: false
-allowed-tools: [filesystem.read, filesystem.list, shell.exec]
----
-# Incident response
-
-Establish the impact, timeline, affected component and current safety boundary
-before changing anything. Preserve evidence and secrets, inspect logs and
-configuration through approved paths, and separate confirmed facts from
-hypotheses.
-
-Prioritize containment, reversible mitigation, data integrity and clear
-rollback. Record commands, observations, decision points and verification. Do
-not delete evidence, rotate credentials, alter production state or apply a
-destructive fix without explicit authorization.

package/skills/performance-review/SKILL.md

@@ -1,17 +0,0 @@
----
-name: performance-review
-description: Find evidence-backed performance bottlenecks and define a measurable safe optimization.
-user-invocable: true
-model-invocable: true
-allowed-tools: [filesystem.read, filesystem.list, shell.exec]
----
-# Performance review
-
-Inspect the complete flow and existing measurements before proposing an
-optimization. Prioritize database and external I/O, duplicate requests,
-blocking CPU work, unbounded concurrency, memory growth and large payloads.
-
-For every finding state the evidence, workload, bottleneck, correctness risks,
-measurement command and acceptance criterion. Do not invent percentage gains or
-recommend caching, memoization, larger pools or infrastructure without an
-invalidation and capacity analysis.

package/skills/refactor/SKILL.md

@@ -1,23 +0,0 @@
----
-name: refactor
-description: Restructure existing code to improve ownership, reuse and testability without changing behavior.
-user-invocable: true
-model-invocable: true
-allowed-tools: [filesystem.read, filesystem.list, filesystem.exists, filesystem.write, shell.exec]
----
-# Refactor
-
-Refactor only when the requested scope has a concrete maintainability or
-correctness benefit.
-
-1. Trace all callers, exports, contracts and tests before moving code.
-2. Separate responsibilities by ownership and dependency direction, not by
-   arbitrary file size.
-3. Reuse existing utilities and preserve public behavior, errors, ordering and
-   side effects.
-4. Keep each extracted unit cohesive and independently testable.
-5. Use a focused diff and verify after each safe extraction, then run the
-   broader regression checks.
-
-Do not combine unrelated cleanup, introduce premature generic abstractions or
-hide behavior changes inside a refactor.

package/skills/release-readiness/SKILL.md

@@ -1,16 +0,0 @@
----
-name: release-readiness
-description: Assess whether a requested change is ready for release across behavior, security, operations and verification.
-user-invocable: true
-model-invocable: false
-allowed-tools: [filesystem.read, filesystem.list, filesystem.exists, shell.exec]
----
-# Release readiness
-
-Inspect the diff, package metadata, build and test configuration, public
-contracts, migrations, configuration, documentation and deployment assumptions.
-
-Check backward compatibility, secret handling, authorization, error and
-rollback behavior, observability, resource cleanup, versioning and file-size
-constraints. Run only documented checks and report blockers, evidence,
-pre-existing failures and unverified runtime risks separately.

package/skills/security-review/SKILL.md

@@ -1,16 +0,0 @@
----
-name: security-review
-description: Review the current workspace for security risks with evidence and safe remediation guidance.
-user-invocable: true
-model-invocable: false
-allowed-tools: [filesystem.exists, filesystem.read, filesystem.list]
----
-
-Review the current workspace for security issues. Trace each relevant input to
-its sensitive sink before reporting it. Prioritize authentication,
-authorization, path traversal, command injection, secret handling, unsafe
-deserialization, and dependency boundaries.
-
-Report only evidence-backed findings. For each finding, include the affected
-file and flow, trigger condition, impact, confidence, and the smallest safe
-remediation. Do not modify files unless the user explicitly asks for a fix.

package/skills/test-plan/SKILL.md

@@ -1,22 +0,0 @@
----
-name: test-plan
-description: Design a focused test plan covering behavior, errors, security and integration boundaries.
-user-invocable: true
-model-invocable: true
-allowed-tools: [filesystem.read, filesystem.list]
----
-# Test plan
-
-Create an implementation-ready test plan for the requested change.
-
-Cover:
-
-- happy paths and important edge cases;
-- runtime validation and stable error behavior;
-- authentication, authorization and trust boundaries;
-- cancellation, timeout and bounded-concurrency behavior;
-- persistence, external adapters and malformed input;
-- the narrow unit test, integration test and final regression command.
-
-For each test, state the setup, action, expected result and why it protects a
-business invariant. Prefer behavior assertions over implementation details.

package/skills/verify/SKILL.md

@@ -1,13 +0,0 @@
----
-name: verify
-description: Identify and run the narrowest relevant verification for the requested workspace change.
-user-invocable: true
-model-invocable: false
-allowed-tools: [filesystem.exists, filesystem.read, filesystem.list, shell.exec]
----
-
-Inspect the workspace documentation and package configuration to determine the
-narrowest relevant verification for the requested scope. Run only commands
-that are documented by the project. Report each command and its result,
-separating pre-existing failures from failures introduced by the requested
-change. Do not edit source files as part of verification.