@enki-dev-expert/global-engineering-standards 0.0.0-stage → 0.1.1

package/docs/security.md

@@ -0,0 +1,373 @@
+
+# Global Application Security Standards
+
+## 1. Mission
+
+Design, develop, operate and maintain secure production-grade applications.
+
+Apply security by design, privacy by design, defense in depth, least privilege, secure defaults and Zero Trust principles where applicable.
+
+These standards apply to web, iOS, Android, backend services, databases, APIs, AI systems and infrastructure.
+
+Security is a mandatory engineering requirement.
+
+No system can be guaranteed completely attack-proof. The objective is to prevent foreseeable attacks, reduce exploitable vulnerabilities, limit damage, detect incidents and support rapid recovery.
+
+## 2. Security Frameworks
+
+Apply the relevant requirements from:
+
+- OWASP Application Security Verification Standard (ASVS) 5.0.
+- OWASP API Security Top 10.
+- OWASP Mobile Application Security Verification Standard (MASVS).
+- OWASP LLM Top 10 for applications using AI.
+- NIST Secure Software Development Framework (SSDF).
+- Applicable privacy and data protection legislation.
+
+Select security controls according to actual risks, data sensitivity and regulatory requirements.
+
+For high-risk applications, evaluate an appropriately demanding ASVS verification level and document the chosen requirements.
+
+Never claim certification or compliance without supporting evidence.
+
+## 3. Threat Modeling
+
+Before developing or significantly modifying security-sensitive functionality:
+
+1. Identify assets requiring protection.
+2. Identify actors and trust boundaries.
+3. Map data flows and external dependencies.
+4. Identify credible attack scenarios.
+5. Estimate likelihood and impact.
+6. Define preventive, detective and recovery controls.
+7. Document residual risks.
+8. Define security acceptance criteria.
+
+Use recognized threat-modeling methods such as STRIDE where appropriate.
+
+Require human approval for material residual risks.
+
+## 4. Authentication
+
+Use proven authentication frameworks and identity providers.
+
+Requirements:
+
+- Secure password hashing when passwords are managed directly.
+- MFA or passkeys when appropriate to the risk.
+- Protection against credential stuffing and brute-force attacks.
+- Secure password reset and account recovery.
+- Session expiration and revocation.
+- Secure handling of authentication tokens.
+- Protection against session fixation and hijacking.
+- Authentication event monitoring.
+- Additional verification for sensitive account operations.
+
+Never implement custom cryptographic authentication protocols without a compelling, reviewed justification.
+
+## 5. Authorization
+
+Authentication does not imply permission to access a resource.
+
+Requirements:
+
+- Enforce authorization on the server.
+- Validate ownership or permitted access for every protected object.
+- Apply least privilege.
+- Deny access by default.
+- Validate roles and permissions at every relevant boundary.
+- Protect administrative operations.
+- Enforce organization and tenant isolation.
+- Test horizontal and vertical privilege escalation.
+- Prevent insecure direct object references.
+
+Never rely solely on frontend permission checks.
+
+## 6. API Security
+
+Protect all relevant API entry points.
+
+Requirements:
+
+- Validate inputs using explicit schemas.
+- Enforce authentication and authorization.
+- Apply appropriate rate limits and quotas.
+- Limit request sizes and resource consumption.
+- Prevent injection and unsafe query construction.
+- Protect against SSRF where external requests are supported.
+- Handle CORS deliberately.
+- Use CSRF protection where applicable.
+- Use secure error responses.
+- Avoid sensitive data in API responses.
+- Apply timeouts and bounded retries.
+- Validate webhook authenticity and replay protection.
+- Use idempotency for operations vulnerable to duplication.
+
+Never expose internal diagnostic details or secrets to unauthorized clients.
+
+## 7. Web Application Security
+
+Evaluate:
+
+- Cross-site scripting.
+- Cross-site request forgery.
+- Injection vulnerabilities.
+- Insecure redirects.
+- Unsafe file uploads.
+- Clickjacking.
+- Content Security Policy.
+- Security-related HTTP headers.
+- Secure cookies.
+- Session handling.
+- Browser storage of sensitive data.
+- Third-party scripts and supply-chain exposure.
+
+Prefer well-maintained framework security mechanisms over custom implementations.
+
+## 8. iOS and Android Security
+
+Follow applicable OWASP MASVS requirements.
+
+Requirements:
+
+- Store sensitive credentials using iOS Keychain or Android Keystore-backed mechanisms where appropriate.
+- Never embed privileged backend secrets in mobile applications.
+- Use secure network communication.
+- Validate authentication and authorization on the backend.
+- Protect sensitive local storage.
+- Minimize permissions.
+- Handle lost, stolen and compromised devices appropriately.
+- Consider device integrity and application attestation where justified.
+- Protect deep links and inter-application communication.
+- Validate incoming push-notification data.
+- Review WebView usage and JavaScript bridges.
+- Apply certificate pinning only when justified and with a safe rotation and recovery strategy.
+- Consider older mobile app versions when evolving backend contracts.
+
+Never assume that obfuscation or client-side protections can replace server-side security.
+
+## 9. Database Security
+
+Requirements:
+
+- Apply least-privilege database roles.
+- Restrict direct database exposure.
+- Enforce resource and tenant isolation.
+- Validate referential integrity.
+- Use parameterized queries.
+- Protect privileged operations.
+- Audit sensitive schema functions.
+- Encrypt connections.
+- Protect database backups.
+- Test restoration.
+- Review database logs for sensitive data exposure.
+
+For Supabase specifically:
+
+- Enable and verify RLS on applicable exposed tables.
+- Review SELECT, INSERT, UPDATE and DELETE policies.
+- Review SQL grants and schema privileges.
+- Audit SECURITY DEFINER functions.
+- Protect service_role and other privileged credentials.
+- Verify Storage bucket and object access.
+- Review Realtime authorization.
+- Secure Edge Functions.
+- Validate multi-user and multi-tenant isolation.
+- Test policies using accounts with different permissions.
+
+Never assume that RLS alone guarantees complete database security.
+
+## 10. Secrets and Cryptography
+
+Requirements:
+
+- Never hardcode secrets.
+- Never commit credentials to Git.
+- Never expose privileged secrets to browser or mobile clients.
+- Never include secrets in logs, documentation or AI prompts.
+- Use appropriate secret-management services.
+- Rotate and revoke compromised credentials.
+- Apply least privilege to machine credentials.
+- Use established cryptographic libraries.
+- Use modern TLS configurations.
+- Encrypt sensitive information at rest where appropriate.
+- Establish secure key lifecycle management.
+- Protect signing keys, encryption keys and recovery credentials.
+
+Never invent custom encryption algorithms.
+
+## 11. Payments and Financial Operations
+
+Where payments are implemented:
+
+- Use established payment providers.
+- Minimize exposure to payment-card information.
+- Do not handle raw card data unless explicitly required and supported by appropriate PCI DSS controls.
+- Validate payment-provider webhooks.
+- Prevent replay attacks and duplicate processing.
+- Use idempotency keys.
+- Verify payment status on trusted systems.
+- Separate payment authorization from fulfillment.
+- Protect refunds and administrative financial operations.
+- Maintain appropriate audit trails.
+- Test partial failures and reconciliation procedures.
+
+Never trust client-side payment confirmation as definitive evidence of successful payment.
+
+## 12. AI and Agent Security
+
+For AI-powered applications:
+
+- Treat external documents, emails, webpages and tool responses as untrusted input.
+- Defend against prompt injection.
+- Restrict agent tool permissions.
+- Validate model-generated outputs before using them in sensitive operations.
+- Prevent data exfiltration through tools.
+- Limit external service access.
+- Require approval for irreversible or high-impact operations.
+- Apply quotas and cost controls.
+- Protect personal information and confidential business data.
+- Evaluate model behavior using representative test cases.
+- Log relevant operational metadata without exposing sensitive content.
+
+Never grant an AI agent unrestricted production access by default.
+
+## 13. Dependency and Supply Chain Security
+
+Requirements:
+
+- Review new dependencies.
+- Prefer maintained and reputable packages.
+- Use dependency locking and reproducible builds where supported.
+- Review licenses.
+- Detect known vulnerabilities.
+- Scan for exposed secrets.
+- Protect CI/CD credentials.
+- Restrict package publishing privileges.
+- Use trusted build and deployment workflows.
+- Investigate unexpected package behavior.
+- Apply security updates according to risk and compatibility.
+
+Never introduce unknown packages simply because an AI-generated solution recommends them.
+
+## 14. Infrastructure Security
+
+Requirements:
+
+- Apply least privilege to infrastructure identities.
+- Protect administrative interfaces.
+- Restrict unnecessary public exposure.
+- Use secure network and firewall configurations.
+- Separate development, staging and production appropriately.
+- Protect infrastructure configuration and deployment credentials.
+- Monitor resource exhaustion.
+- Implement relevant DDoS mitigations.
+- Apply secure defaults.
+- Maintain tested backup and recovery procedures.
+- Document infrastructure changes.
+- Review third-party integrations.
+
+## 15. Logging and Monitoring
+
+Implement risk-appropriate:
+
+- Structured security logs.
+- Authentication and authorization event monitoring.
+- Administrative activity tracking.
+- API abuse detection.
+- Suspicious traffic alerts.
+- Dependency vulnerability alerts.
+- Infrastructure monitoring.
+- Incident escalation.
+- Data-access audit trails.
+- Retention and access policies for logs.
+
+Never record passwords, access tokens or other secrets in logs.
+
+Minimize personal data in telemetry.
+
+## 16. Incident Response
+
+Establish procedures for:
+
+1. Detection.
+2. Classification.
+3. Containment.
+4. Investigation.
+5. Credential revocation when required.
+6. Recovery.
+7. Legal and regulatory assessment.
+8. Notification when legally required.
+9. Post-incident analysis.
+10. Corrective actions.
+
+For personal data breaches, evaluate notification obligations under applicable law, including GDPR Articles 33 and 34 where relevant.
+
+Do not assume every security incident automatically requires notification within 72 hours.
+
+## 17. Security Verification
+
+For significant security-sensitive changes:
+
+- Perform relevant static analysis.
+- Evaluate dependency vulnerabilities.
+- Run secret scanning.
+- Test authentication.
+- Test authorization.
+- Test tenant isolation.
+- Test relevant API abuse scenarios.
+- Review cryptographic usage.
+- Verify configuration and infrastructure permissions.
+- Validate security-related regressions.
+- Perform dynamic testing and authorized penetration testing where warranted.
+
+Use independent review for high-risk systems when justified.
+
+Never claim a security test passed without executing it.
+
+## 18. Release Security Gates
+
+Before production release, verify:
+
+- Applicable security requirements are documented.
+- Critical security findings are resolved or subject to explicitly approved risk handling.
+- Relevant authorization tests pass.
+- Secrets are protected.
+- Dependency risks are reviewed.
+- Security-sensitive configurations are verified.
+- Backups and recovery procedures are available.
+- Monitoring and incident response procedures exist.
+- Residual risks are documented.
+- Required human approvals are complete.
+
+A successful build alone is not evidence of security.
+
+## 19. Change Management
+
+Before significant security-related changes:
+
+1. Inspect current functionality.
+2. Identify affected security boundaries.
+3. Explain risks and proposed mitigations.
+4. Evaluate backward compatibility.
+5. Propose tests and rollback procedures.
+6. Obtain explicit approval.
+7. Implement only the approved scope.
+8. Verify the results.
+9. Report unresolved risks.
+
+Stop and request approval if unexpected risks or changes of scope arise.
+
+## 20. Final Security Principles
+
+Assume breach.
+Verify explicitly.
+Apply least privilege.
+Minimize attack surfaces.
+Protect data at every boundary.
+Never trust client-side authorization.
+Never expose privileged secrets.
+Validate with evidence.
+Monitor continuously.
+Prepare for recovery.
+Never weaken security silently.

package/handbook/claude-plugin.md

@@ -0,0 +1,31 @@
+# Optional Claude Code plugin
+
+The standalone CLI is the complete installation path for automatic policy plus skills. The optional plugin distributes the six skills only. Installing it does not activate AGENTS.md or a global CLAUDE.md policy. Use the CLI for that requirement.
+
+## Prepared artifacts
+
+`npm run build` creates:
+
+- `dist/claude-plugin/.claude-plugin/plugin.json`.
+- Six `dist/claude-plugin/skills/<name>/SKILL.md` files.
+- Copied domain documents, templates and AGENTS.md with plugin-relative references.
+- `.claude-plugin/marketplace.json`, with a relative source of `./dist/claude-plugin`.
+
+The plugin has no hooks, commands that execute shell code, MCP servers, external services or automatic permission changes. Skills are namespaced, for example `/global-engineering-standards:engineering-security-standards-check`. The local marketplace name is `enki-engineering-standards`.
+
+## Local validation and trial
+
+After building, the vendor CLI can validate the plugin directory and marketplace manifest with `claude plugin validate`. For a temporary trial, use `claude --plugin-dir /path/to/reviewed-checkout/dist/claude-plugin` inside an isolated home/project. To persistently install a local marketplace, the documented commands are:
+
+```sh
+claude plugin marketplace add /path/to/reviewed-checkout
+claude plugin install global-engineering-standards@enki-engineering-standards
+```
+
+These persistent commands modify the selected Claude configuration and are documentation only; they were not run against the maintainer's real configuration. Avoid enabling both plugin skills and standalone Claude skill copies unless duplicate namespaced availability is intentional.
+
+## Distribution limitation
+
+The marketplace currently references a generated, ignored `dist/` directory. A raw Git checkout without `npm run build` cannot install the plugin. Do not advertise GitHub marketplace installation yet. A future plugin release must ship a complete generated marketplace directory or adopt a reviewed artifact-hosting path. The npm package intentionally ships the standalone CLI; it does not include the generated plugin tree.
+
+Official format sources: [plugin manifests](https://code.claude.com/docs/en/plugins-reference), [marketplaces](https://code.claude.com/docs/en/plugin-marketplaces). See [actual validation results](validation.md) for the exact boundary of testing; schema validation does not establish semantic behavior in a model session.

package/handbook/compatibility.md

@@ -0,0 +1,27 @@
+# Agent compatibility
+
+Official documentation reviewed on 2026-10-20. Documentation conformity and local filesystem tests are distinct from a successful authenticated agent session. No model session or paid inference was required for this preparation.
+
+## Claude Code
+
+The CLI writes user policy to `~/.claude/CLAUDE.md` or project policy to `CLAUDE.md`, and copies skills into the corresponding `.claude/skills/<name>/SKILL.md`. `CLAUDE_CONFIG_DIR` is honored for global configuration. Existing settings, permissions, MCP connections and unrelated skills remain untouched.
+
+Policy is embedded in a managed block rather than relying on import parsing or AGENTS.md fallback behavior. This avoids uncertainty with import paths containing spaces and version-dependent direct AGENTS.md loading. Claude configuration or enterprise policy can still exclude project instructions or disable local skills. Restart and verify discovery in the actual supported client.
+
+Sources: [Claude memory](https://code.claude.com/docs/en/memory), [Claude skills](https://code.claude.com/docs/en/skills), [Claude settings](https://code.claude.com/docs/en/settings).
+
+## Codex
+
+Global policy goes to `$CODEX_HOME/AGENTS.md`, defaulting to `~/.codex/AGENTS.md`. Project policy goes to `AGENTS.md`. Current documented skill discovery uses `~/.agents/skills` for user skills and `.agents/skills` within projects. The CLI does not install new skills into the older `.codex/skills` location or remove existing ones there.
+
+A nonempty `AGENTS.override.md` at the managed instruction location causes a conflict. Codex combines project instructions subject to a default 32 KiB budget. The installer checks its destination file size, but does not parse or change `config.toml`, inspect every ancestor's policy, or override custom size limits. Existing skills elsewhere or enterprise settings may shadow/disable the installed copies. The user must inspect actual discovery after restarting.
+
+Sources: [Codex instruction discovery](https://developers.openai.com/codex/guides/agents-md), [Codex skill locations](https://developers.openai.com/codex/skills).
+
+## Platform and path behavior
+
+The CLI uses Node filesystem APIs, path handling and exclusive file locks, with no shell-specific install commands or symlinks. Windows path layouts are unit-tested; full native Windows and Linux results require running the prepared CI matrix. macOS filesystem behavior is validated locally.
+
+Project references are relative to their containing file, so a checkout can move. Global references are absolute; rerun from the same configuration roots. Moving a global installation or changing environment overrides without reinstalling is unsupported. Symlinked configuration directories and instruction files are deliberately refused rather than followed.
+
+Node 22/24 are CI targets. Minimum Node support does not imply every agent version supports these conventions. Agent cloud environments, sandbox read restrictions, remote home mappings, corporate policy, custom document budgets and future vendor changes need separate validation. This framework does not claim vendor endorsement.

package/handbook/recovery.md

@@ -0,0 +1,29 @@
+# Updates, backups and recovery
+
+An installation's state is `.engineering-standards/` inside the selected home or project. It contains `framework/`, `manifest.json`, a temporary `operation.lock`, and `transactions/`.
+
+The manifest records a schema version, package version, scope, installed agents, file hashes and exact managed instruction blocks. It stores logical target identifiers, not arbitrary destination paths. Target paths are derived from scope and current configuration roots. Do not change those roots between install and recovery.
+
+Before changing files, the CLI validates the entire plan and records before/after snapshots and modes in a private transaction journal. Each file uses a same-directory temporary file, a flush, and a rename. Caught failures restore completed writes if they still match expected content. The transaction remains available for inspection. Empty directories may remain after a failed installation or uninstall; no recursive cleanup is performed.
+
+## Routine rollback
+
+Run `rollback --dry-run` with the original scope, then `rollback`. This targets the newest transaction not already rolled back. A rollback refuses to overwrite later user edits. Each successful rollback permits stepping back one more transaction. Uninstall can be rolled back while its snapshots remain available.
+
+Snapshots are backups, not encrypted archives. They can contain private user instructions. Exclude `transactions/` and `operation.lock` from source control. Backups are retained until you explicitly remove them after reviewing retention and recovery needs. Repeated no-op installations create no new transaction backup.
+
+## Conflicts
+
+If an owned file changed, copy your work to a safe location and review the difference against the journal. Restore the expected managed content only if you intend to relinquish those edits; then rerun the operation. Do not remove or rewrite the manifest to force deletion. User edits outside a managed instruction block are preserved by update and uninstall, but a whole-transaction rollback requires the exact recorded after-state.
+
+Unknown same-named skills are never adopted. Rename or move them yourself only after considering agent discovery and preserving a backup. Empty skill directories are reusable.
+
+## Interrupted process
+
+A process killed before releasing its lock leaves `operation.lock`. The CLI will not guess whether a process is still active. Inspect running processes and the newest journal, preserve a copy, and remove only the stale lock once you are certain no installer is running. Then run `rollback --dry-run`, followed by `rollback`. A pending journal accepts files in either their recorded before or after state, supporting interruption during both installation and rollback.
+
+`doctor` reports a missing/invalid manifest, missing or edited files, override conflicts, active/stale locks and pending transactions. A crash during the first installation can occur before the manifest exists; inspect `transactions/` and use rollback directly.
+
+A crash before the initial journal is fully written makes no target modifications; an orphan `.ges-*.tmp` file may remain. Review such files manually. File flushes and atomic renames are not a guarantee of cross-file atomicity or power-loss durability on every filesystem. Restore from an independent backup if journals are damaged.
+
+Windows ACLs and POSIX ownership/extended attributes are not fully serialized. Existing file permission bits are preserved where the platform supports them. Do not run this installer as a privileged administrator or in directories writable by untrusted users.

package/handbook/releasing.md

@@ -0,0 +1,50 @@
+# Release preparation and publication
+
+**Nirox Morais** is the project author and copyright owner; **Enki-DEV-expert** is the GitHub account and project maintainer responsible for authorizing publication. This release preparation creates no tags, npm publication or GitHub releases.
+
+## Before publishing the repository
+
+1. Review all added files and the original-content checksum report. Existing untracked standards must not be discarded.
+2. The configured public repository target is `Enki-DEV-expert/engineering-standards`; confirm that the repository was created at this address before publishing. Package and citation metadata now use this URL.
+3. Enable and test private vulnerability reporting. Replace the private security/conduct channel placeholders with real maintainer-approved channels.
+4. Review the MIT copyright, authorship, issue templates, contribution process and residual security risks.
+5. Configure branch/tag protection, required CI checks and reviewed dependency updates. Run the prepared Linux/macOS/Windows matrix; local macOS results do not establish other platforms.
+6. Review and cryptographically verify the GitHub Action commit pins against upstream releases and security advisories. They are deliberately pinned; Dependabot may propose reviewed updates.
+7. Personally create signed commits and an annotated signed release tag only after approving the diff. See [signing](signing.md). Do not add AI co-authorship trailers.
+
+## Before publishing npm
+
+The proposed name is `@enki-dev-expert/global-engineering-standards`. A GitHub username does not establish npm scope ownership. Confirm scope control, public-package availability and the final package name first. Update package metadata, lockfile and documentation if the name changes.
+
+Run:
+
+```sh
+npm ci --ignore-scripts
+npm run check
+npm run package:check
+npm audit
+```
+
+The package smoke check packs into a temporary directory with lifecycle scripts disabled, checks an explicit file allowlist, installs/runs/uninstalls the packed CLI in an isolated home/project and copies the tested tarball plus SHA256SUMS into `dist/artifacts/`. It does not publish anything. Review the actual tarball contents, dependency advisories and checksum before release.
+
+Confirm `package.json`, `CITATION.cff` and the GitHub repository all identify `Enki-DEV-expert/engineering-standards`. Synchronize package, plugin and changelog versions. Add a release date only when actually released.
+
+Configure npm trusted publishing for the exact GitHub owner, repository, `release.yml` and `npm-release` environment. Protect that environment with a human approval and restrict deployment tags. Enable GitHub private vulnerability reporting and npm account protections before publication. Bootstrap a new npm package manually through the account's approved workflow if trusted-publisher configuration requires an existing package; this preparation does not assume a first-publish identity exists.
+
+The prepared workflow uses GitHub-hosted runners and OIDC without a stored npm token. npm documents Node >=22.14.0 and npm >=11.5.1 for trusted publishing; verify the runner's installed versions at release time. Sources: [npm trusted publishing](https://docs.npmjs.com/trusted-publishers/), [npm provenance](https://docs.npmjs.com/generating-provenance-statements/).
+
+## Prepared release workflow
+
+`.github/workflows/release.yml` has only a manual trigger. Its verification job requires repository variable `NPM_RELEASE_ENABLED=true`, the exact confirmation text, and a version tag matching package.json. It checks repository identity, version, annotated signature presence, authorship trailers, all quality gates and package contents. **Signature presence is not cryptographic trust verification**: verify the signed commit/tag locally using the trusted maintainer key before approving the protected environment.
+
+The publish job receives only `contents: read` and `id-token: write`, downloads the tested artifact, verifies its SHA-256 and publishes that tarball with provenance and lifecycle scripts disabled. Artifacts expire after seven days. It does not create a GitHub release. Neither enabling the gate nor dispatching the workflow was performed in this preparation.
+
+The maintainer must establish the protected environment before setting the enable variable; a workflow file alone does not configure GitHub approvals. Never run publication from a pull-request context or supply a long-lived token as a workaround for missing OIDC setup.
+
+## Optional plugin release
+
+The local marketplace points at generated files. A raw repository checkout without a build is not a ready remote marketplace. Before advertising a marketplace URL, prepare a complete marketplace artifact with the plugin tree present, verify it with Claude Code and test an isolated install. No remote marketplace availability is currently claimed.
+
+## After a future release
+
+Verify npm provenance against the expected repository/workflow/ref, download the published tarball, compare its checksum, and smoke-test in a clean environment. Record the actual release in CHANGELOG.md and citation metadata. If a defect appears, deprecate or supersede according to npm policy and coordinate a fix; do not assume package unpublication is always available or safe.

package/handbook/security-review.md

@@ -0,0 +1,41 @@
+# Installer security and privacy review
+
+Scope: local CLI source, bundled standards, tests, package boundary and prepared workflows. Procedures applied: engineering-safe-implementation, engineering-security-standards-check and engineering-architecture-review. This is an implementation review, not independent penetration testing or certification.
+
+## Assets and trust boundaries
+
+Assets are existing agent instructions/skills, private configuration, project files, installation state and release credentials. Inputs include CLI arguments, scope/environment paths, bundled content, local manifests/journals and existing files. The CLI is intentionally offline and executes no external programs. Only the developer build/test and future release workflows use external tools.
+
+The package and current OS user are trusted. Existing instructions may be sensitive. Other users must not have write access to the installation tree. An attacker controlling the same account or replacing the executable/package can bypass a local ownership scheme; checksums do not authenticate a maliciously replaced baseline.
+
+## Controls and evidence
+
+| Threat | Implemented mitigation | Verification |
+| --- | --- | --- |
+| Existing instructions lost | Append owned blocks; preserve other bytes, BOM and line endings | Preservation and uninstall tests |
+| Unrelated skills overwritten | Refuse populated same-named directories | Skill conflict tests |
+| Edited managed content deleted | Verify hashes/blocks before the whole operation | Update/uninstall refusal tests |
+| Path traversal through state | Logical target allowlist; reject unknown keys | Malformed manifest/journal tests |
+| Link redirection | Inspect path components; reject symlinks and hard-linked files | Link refusal tests |
+| Interrupted multi-file write | Preflight, before/after journal, rollback, exclusive lock | Failure-injection and recovery tests |
+| Later edits overwritten by recovery | Exact snapshot comparisons | Rollback conflict tests |
+| Credentials leaked in output | Output logical change names, never snapshot contents | Source review; no telemetry |
+| Accidental publication | Manual workflow, disabled repository-variable gate, protected environment | Workflow review; never dispatched |
+| Dependency execution | Zero runtime dependencies; locked development tools; ignore install scripts in CI | Lockfile and package review |
+
+## Residual findings and limitations
+
+- **Medium, local trust constraint:** path inspection and rename are not a fully race-free filesystem capability boundary. Concurrent malicious directory replacement can race checks. Mitigation: user-owned trusted directories, no administrator execution, no world-writable destinations; installer locks coordinate this CLI only. Hostile multi-user directory support is not claimed.
+- **Medium, recovery durability constraint:** per-file fsync/rename does not provide a single atomic transaction across all files or guarantee journal durability after power loss. Abrupt termination can leave a lock or temporary file. Mitigation: retained journals, explicit recovery and independent backups for important configuration.
+- **Medium, privacy:** backup journals contain prior user instruction content in base64, not encryption. POSIX permissions restrict newly created files/directories; Windows ACLs are inherited. Mitigation: source-control exclusions, local access restrictions and manual retention review. Existing state directories may have broader pre-existing permissions and must be reviewed by the operator.
+- **Medium, launch prerequisite:** private vulnerability and conduct reporting contacts are not configured by this work. Enable and test private GitHub reporting and supply a conduct contact before launch.
+- **Low, semantic integration:** agent discovery/preference, instruction budgets, corporate restrictions and conflicting user policies can limit activation. `doctor` does not prove model compliance. Use an isolated authenticated session before claiming full runtime compatibility.
+- **Low, supply chain:** pinning reduces drift but does not eliminate compromise. Verify action pins, package contents, dependency advisories and npm provenance at release time.
+
+These are reported constraints, not self-approved policy exceptions. The maintainer must review them before publication. No production operations, financial commitments, sensitive external processing, Git commits, pushes or releases are part of this preparation. No command targeted live agent configuration for modification; the exact preservation evidence and metadata limitations are recorded in [validation](validation.md).
+
+## Content and policy review
+
+All twelve standards and six skills were included in inventory, heading/reference, content-hash and sensitive-pattern checks. The implementation-specific review focused on governance, filesystem/CLI standards, architecture, security, privacy, quality, costs and operational recovery. Original text is unchanged. Fixed home-path examples remain in canonical skills/templates to preserve their behavior; generated copies adapt them to the real destination.
+
+Generic domain documents sometimes say to obtain approval before significant work, while governance and skills define prior scoped autonomous authorization. This task has explicit local autonomous authorization; protected publication and production actions remain unapproved. The installer neither rewrites those policies nor attempts to resolve semantic conflicts with a user's other instructions.

package/handbook/signing.md

@@ -0,0 +1,18 @@
+# Maintainer commit and tag signing
+
+The project author and copyright owner is Nirox Morais; the GitHub account and project maintainer is Enki-DEV-expert. Use the maintainer's existing GitHub-associated email and set the commit author name to Nirox Morais. This preparation does not change the persistent Git identity, create signing keys or create tags. Never add AI co-authorship trailers.
+
+Before the maintainer commits, inspect the staged diff, confirm author identity and use an existing approved signing key. Git supports GPG or SSH signing; configure the chosen signing method through the maintainer's normal secure key-management process. Keep private keys and passphrases outside this repository. Register the public signing key with GitHub if a verified badge is desired.
+
+After review, commands such as these are **manual examples**, not commands executed by this preparation:
+
+```sh
+git commit -S -m "Prepare engineering standards distribution"
+git tag -s v0.1.0 -m "Global Engineering Standards 0.1.0"
+git verify-commit HEAD
+git verify-tag v0.1.0
+```
+
+Use the final approved version, not an assumed release number. Verification must use a trusted signer configuration: GPG trust or an SSH allowed-signers file whose maintainer key fingerprint has been checked out of band. A signature block alone is insufficient.
+
+Before any push/publication, verify the tag points to the reviewed commit and that the version matches package.json. Tag protection and the protected release environment should restrict publication to maintainer-reviewed tags. Do not expose signing secrets to pull-request workflows. The prepared release script checks signature presence; cryptographic trust verification remains a required maintainer action before release approval.

package/handbook/validation.md

@@ -0,0 +1,50 @@
+# Validation record
+
+Release preparation date: 2026-10-20. Status: local development and checks completed; publication and full platform/agent runtime certification remain unperformed.
+
+## Actual local environment
+
+- macOS, Node.js 24.21.0, npm 11.19.0.
+- Development tooling: TypeScript 7.0.2, Biome 2.5.15, Node 22 type definitions 22.20.5, with exact lockfile versions.
+- Vendor CLIs inspected only in temporary homes: Claude Code 2.1.304 and codex-cli 0.163.0.
+
+## Executed checks
+
+| Check | Actual result |
+| --- | --- |
+| `npm run check` | Passed: lint, strict type checking, build, 50 tests and standards validation |
+| Isolated installer tests | 50 passed, 0 failed, 0 skipped |
+| `npm run package:check` | Passed: 51 allowlisted package files; packed CLI init, doctor, update, uninstall; offline npm installation and executable discovery |
+| Original content checksums | 23/23 unchanged: AGENTS.md, twelve documents, six skills and four templates |
+| Content validation | Domain/template references, six skill frontmatter records, generated plugin inventory and local Markdown links passed |
+| Repository pattern scan | No matched secret/private-path/AI-trailer indicators in the 64 candidate distributable repository files; bounded heuristics, not a guarantee |
+| `claude plugin validate` | Generated plugin and marketplace both passed, no warnings, with isolated HOME/configuration |
+| YAML parsing | Both workflows, issue forms/config, Dependabot and CITATION.cff parsed successfully using Ruby YAML; not a formal CFF schema certification |
+| Dependency audit | Networked npm installation reported 0 vulnerabilities; subsequent cached/offline npm audit also reported 0. Fresh advisory review remains a release gate |
+| `git diff --check` | Passed, but the repository has no commits and its candidate files are untracked, so this is not a substantive tracked-diff review |
+
+The generated tarball and SHA256SUMS are in `dist/artifacts/`, ignored by Git. Regenerating the artifact after documentation edits changes the checksum; use the checksum accompanying the actual reviewed artifact.
+
+## Coverage
+
+Tests cover global/project scope; Claude-only, Codex-only and both agents; custom configuration roots; repeat installation; preservation of BOM/CRLF/user bytes/settings/unrelated skills; existing skill collisions; real content/version updates and rollback; dry-run; uninstall; interrupted installation; failure injection; locks; altered manifests/backups; missing files; malformed skill metadata; broken document references; symlinks/hard links; Codex overrides and size limits; relocated projects; Windows/POSIX layouts; spaces, Unicode and literal dollar tokens in paths; control-character rejection; and preservation of user resources added inside managed skill directories.
+
+Tests create temporary homes and projects and isolate subprocess configuration. No test targets live agent installation directories. There are no production or paid-service tests.
+
+## Live configuration preservation
+
+A read-only baseline covered 939 entries in the live Claude/Codex instructions, settings and skill trees, including `.agents/skills`. The final comparison found **zero content, symlink-target or inventory changes**. Two files in Claude's synced-skill bookkeeping had different modification timestamps but identical content hashes. Their cause is not established by this comparison; this preparation did not restore or modify those timestamps. This distinction prevents claiming that every live filesystem metadata field remained unchanged. The separate `~/.claude.json` application-state file was not included in the initial content baseline and had a later modification time; its complete preservation cannot be established from this evidence. No cause is attributed and no attempt was made to restore live application state.
+
+No installer command targeted the real home or live agent configuration. All vendor CLI validation commands were launched with temporary HOME, USERPROFILE, CODEX_HOME and CLAUDE_CONFIG_DIR values. The baseline contains no private file contents in this repository.
+
+## Existing local backup
+
+One pre-existing AGENTS.md backup remains in the working directory. It is matched by the original backup ignore rule and is excluded from the npm allowlist. It was preserved rather than deleted. Do not force-add ignored backups during publication.
+
+## Unverified boundaries and required follow-up
+
+The prepared CI matrix targets Node 22/24 on Linux, macOS and Windows. Those hosted jobs have not run. Native Windows layout unit tests do not substitute for Windows filesystem/ACL tests. Authenticated Claude/Codex instruction loading and semantic behavior have not been exercised by a model session during this preparation.
+
+Plugin validation establishes accepted manifest structure; it does not prove runtime invocation, account permissions or automatic policy loading. The plugin is skills-only, and the generated marketplace tree is not yet a publicly distributable Git marketplace.
+
+No commits, tags, pushes, GitHub releases, npm publication, marketplace registration or release workflow dispatch were performed. Repository identity, npm scope ownership, private reporting channels, protected release environment, signing trust and fresh upstream security review remain maintainer release prerequisites.