dsh-env-manager-plugin 0.0.0-stage → 0.1.1

package/cordis.patch.yml

@@ -0,0 +1,4 @@
+- insert:
+    - id: dsh-env-manager
+      name: dsh-env-manager-plugin
+      config: {}

package/docs/00-project/current-state.md

@@ -0,0 +1,272 @@
+# Current State
+
+This file is the **project continuity snapshot**. Update it after every completed change.
+
+## Current Phase
+
+**Phase 1 of the environment/plane model and Phase 1.1 of the K8s node/execution model
+are implemented, tested and live-verified in the `desktop` profile: an environment is one
+network, its planes are role views, and hosts also record their machine kind and command
+surfaces.**
+
+The V1 Host is implemented in TypeScript under `src/` and compiled to `lib/`. Storage,
+registry, resolver, router, session store, application service, ten tools and the
+same-origin HTTP API are in place, with 51 Vitest tests passing. The Client panel is
+implemented in `client.js` and its sidebar/main slot registrations are live. The sidebar
+glyph follows the host `sidebar.panellist` contract: it honors the owner's
+`size`/`active` props and renders monochrome with `currentColor`; the contract is recorded
+in [`client-ui-integration.md`](../02-harness/client-ui-integration.md).
+
+The plugin also registers a profile-wide **discovery Skill** named `dsh-env-manager` via
+`ctx.skills.register()`. Its catalog entry makes the registry discoverable from any
+workspace in the same profile; its full workflow body loads only on invocation. It is a
+discovery/usage Skill, not an execution Skill or operation binding, and it is removed
+when the plugin is disabled or uninstalled. `config.registerSkill` defaults to `true`.
+
+Release packaging is prepared under the npm name `dsh-env-manager-plugin` because the
+unscoped `dsh-env-manager` npm name is an unrelated existing package. Pushing an
+annotated `v*` tag runs [`.github/workflows/release.yml`](../../.github/workflows/release.yml)
+on `windows-latest`, verifies the tag against `package.json`, runs `npm run check`, packs
+the tarball, publishes with npm Trusted Publisher/OIDC, and creates a GitHub Release.
+The first publish must be bootstrapped manually before Trusted Publisher can be bound;
+the exact steps are in [`release.md`](../06-operations/release.md).
+
+**Release status (2026-11-01):** `dsh-env-manager-plugin@0.1.0` is published and is the
+`latest` npm tag (`gitHead` `4d884e7`). The
+[GitHub Release v0.1.0](https://github.com/zhiwuli0228/dsh-env-manager/releases/tag/v0.1.0)
+contains `dsh-env-manager-plugin-0.1.0.tgz`; workflow run
+[`41323001406`](https://github.com/zhiwuli0228/dsh-env-manager/actions/runs/41323001406)
+completed successfully. The 0.1.0 publish itself was bootstrapped manually; the workflow
+detected the existing version, skipped npm publish, and created the Release. Later versions
+use npm Trusted Publisher/OIDC through the same workflow.
+
+**Plugin directory:** submitted to
+[`awesome-dsh-plugin/awesome-dsh-plugin`](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin)
+as PR [#11185](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/11185)
+(`data/plugins/zhiwuli0228__dsh-env-manager.yml`, category `dev`). The repository has the
+`dsh-plugin` topic; the listing is pending CI/review.
+
+**Installation smoke test (2026-11-02):** removed the old local bundle
+`dsh-env-manager` from the `desktop` profile, including its package dependency, bundle
+entry, lockfile reference and stale `node_modules/dsh-env-manager` symlink. Reinstalled
+the published package as `dsh-env-manager-plugin@0.1.0` from npm. The discovery Skill,
+ten tools, sidebar panel and `/env-manager/api` transport all came back; the API reported
+the preserved registry data (2 environments, 3 services, 3 deployments, 0 rule profiles,
+0 operation bindings) and no warnings. Registry data was intentionally not deleted during
+uninstall.
+
+**Install hardening (2026-11-03):** reproduced the reported failure from a clean clone:
+`lib/` was git-ignored, so a checkout installed without a build had no `lib/index.js`.
+The compiled `lib/` tree is now committed, `index.js` reports a specific missing-build
+error, and the install docs use `plugin_manager install_bundle` instead of the
+dependency-only `dsh plugin add` command. `scripts/repair-profile.mjs` detects duplicate
+or legacy bundle entries and offers an atomic `--fix` with a backup. The published
+`0.1.0` npm tarball already contained `lib/`; this fixes checkout and git installs.
+
+The panel uses a centered 1080 px column, 22 px title with a glyph mark, underline tabs,
+compact stat cards and a master/detail environment view. **Environments is the first and
+default tab**; a persistent header **New environment** action is available from every tab,
+and `Records` is limited to services, deployments, rule profiles and operation bindings.
+
+Phase 1 changes the environment workflow:
+
+- `New environment` creates only the shell: name, optional id, category and description.
+  It seeds the four standard roles (`management`, `business`, `database`, `extension`) and
+  creates no hosts, endpoints or credentials.
+- The detail page is grouped by role: Overview, All nodes, one tab per declared plane,
+  Login records, Kubernetes/clusters, Endpoints and YAML. Plane tabs are filters over the
+  same `hosts[]`; a node serving two planes is one host with two roles and appears in both
+  tabs.
+- Add/edit node supports multiple roles. Opening the form from a plane preselects that
+  role. A node may have zero accounts, or an optional login username + password that
+  writes a namespaced credential and keeps only `credentialRef` in YAML. On edit, filling
+  both fields adds a new password account and leaves existing accounts untouched.
+- Batch import accepts `IP,name,roles,port,user` per line, with `|`/`/` for multiple
+  roles. It creates hosts and optional accounts but never passwords, and rejects unknown
+  roles/duplicate IPs/invalid ports before saving.
+- Node search filters by id, name, IP, platform, admin user, role, node kind, access
+  method, cluster name/id, account username or web login URL. Node cards expand to show the
+  account table.
+- Schema validation now requires at least one environment role and at least one role per
+  host. Standard roles are seeded automatically when a node uses a missing standard role.
+
+Phase 1.1 adds the K8s node/execution model (ADR-0011):
+
+- `Host.kind` classifies the machine as `vm`, `physical`, `k8s-all-in-one`, `k8s-worker`
+  or `pod-host`. A missing value reads as `vm`.
+- `Host.access` records `ssh`, `kubectl` and/or `docker`; it is capability metadata, not
+  authorization. `Host.clusterRef` links K8s/Pod machines to a cluster.
+- `k8s-all-in-one` and `k8s-worker` require an existing cluster reference; `pod-host` may
+  omit it for a Docker-only machine. A Pod is never a Host; `pod-host` is the machine
+  reached with `docker exec`.
+- `Cluster.topology` is `all-in-one`, `separate` or `external` and is optional.
+- The node form has kind/cluster/access controls; node cards and search include kind,
+  access and cluster; the detail page has a Kubernetes/clusters tab with add/edit and a
+  node count derived from `clusterRef`.
+- Batch import remains generic VM (`kind: vm`, `access: [ssh]`) and never accepts secrets.
+
+Web console logins are account-level:
+
+- `HostAccount.loginUrl` stores the management/business console URL; it is a URL, not a
+  secret. The account form has `Web login URL`, username and an optional password, and the
+  account can be edited in place. The Host schema requires an absolute `http(s)` URL.
+- `Add web login` on a node card opens the account form with protocol `web` and auth type
+  `password` preselected; the URL renders as a link under the account username.
+- A password entered in the account form is written through the DSH credential service;
+  YAML keeps only `credentialRef`. Leaving the password blank preserves the existing
+  reference when editing.
+- Account search covers username, purpose and web login URL.
+
+Live verification covered shell creation, plane tabs, empty-plane state, add node from a
+plane, multi-role edit, batch import, search, account creation and credential references.
+Phase 1.1 was additionally verified live: add a cluster with topology and API endpoint, add
+a K8s all-in-one node with kind/access/cluster, add a Pod host without a cluster, reject a
+K8s worker without a cluster, confirm cluster/node counts and search by cluster name.
+Web login URL/password and account edit were verified live after the account form change.
+
+## Implemented
+
+Documentation and repository:
+
+- [x] GitHub repository initialized
+- [x] DSH bundle manifest (`package.json`, `cordis.patch.yml`)
+- [x] Host plugin entry shim (`index.js` → `lib/index.js`)
+- [x] Client panel (`client.js`)
+- [x] Locale resources (`locale/en.json`, `locale/zh.json`)
+- [x] Plugin icon (`icon.svg`)
+- [x] README, LICENSE, `.gitignore`
+- [x] Docs Harness Context Hub
+- [x] AGENTS.md project rules
+- [x] V1 design suite:
+  - [x] `design.md` — scope, architecture, flows, acceptance criteria
+  - [x] `detailed-design.md` — module contracts, algorithms, storage, tools, HTTP
+  - [x] `data-model.md` — record schemas, results, diagnostics catalogue
+  - [x] `tool-contract.md` — ten model-facing tools with DSL schemas and errors
+  - [x] `storage-contract.md` — dataDir resolution, atomicity, sessions, backups
+  - [x] `module-boundaries.md` — ownership and dependency direction
+  - [x] `ui-design.md` — panel layout, transport, states, i18n, QA checklist
+  - [x] `security-model.md` — credentials, approval, HTTP controls, redaction
+  - [x] `api-verification.md` — verified runtime facts F1–F21 and probes V1–V8
+  - [x] `implementation-plan.md` — ordered tasks T01–T24, acceptance, cut line
+  - [x] ADR-0001 … ADR-0011
+
+Code:
+
+- [x] TypeScript Host scaffold (`src/`, `tsconfig.json`, build scripts)
+- [x] Domain schemas and validators
+- [x] Storage layer with atomic writes, backups and session files
+- [x] Registry layer with integrity diagnostics
+- [x] Context resolver
+- [x] Rule resolver with provenance
+- [x] Operation Skill router
+- [x] Profile-wide discovery Skill (`dsh-env-manager`) registered through `ctx.skills.register()`
+- [x] README documents the bundled Skill lifecycle, scope, opt-out and execution boundary
+- [x] GitHub Actions release pipeline (`.github/workflows/release.yml`) for tagged npm publish
+- [x] Release runbook (`docs/06-operations/release.md`) with Trusted Publisher bootstrap
+- [x] Session context store
+- [x] Application service (`app`)
+- [x] Read tools
+- [x] Management tools
+- [x] HTTP transport
+- [x] Client configuration UI (slot registration and HTTP round-trip live-verified)
+- [x] Environment detail: overview, role/plane views, nodes, accounts, login audit, clusters, endpoints, YAML
+- [x] Shell-only **New environment** form with standard role seeding
+- [x] Role-filtered plane tabs over one `hosts[]` collection (no per-plane copies)
+- [x] Add/edit node with multiple roles and optional credential write
+- [x] Node kind (`vm`/`physical`/K8s all-in-one/K8s worker/Pod host), command access and cluster reference
+- [x] Kubernetes/clusters tab with cluster add/edit, topology and derived node count
+- [x] Batch node import (`IP,name,roles,port,user`; no passwords; generic VM nodes)
+- [x] Node search (including kind/access/cluster and account web login) and expandable account cards
+- [x] Account-level web login URL, password-to-credential bridge and in-place account edit
+- [x] Dedicated default **Environments** tab and persistent header create action
+- [x] Records narrowed to services, deployments, rule profiles and operation bindings
+- [x] Credential write path (`credential` / `credentialUnset`, namespaced refs)
+- [x] Structured forms for basic info, node, account and login records
+- [x] Memory bridge contract and null adapter
+- [x] Tests (50 passing)
+- [x] Installed in the `desktop` profile (`install_bundle`, `application: applied`)
+
+## Current Constraints
+
+- V1 accepts `schemaVersion: 1` only.
+- No plain-text credentials in registry files.
+- An environment must declare at least one logical role and every node must declare at
+  least one declared role; the four standard roles are seeded on shell creation.
+- `k8s-all-in-one` and `k8s-worker` nodes require a valid `clusterRef`; `pod-host` may omit
+  it for a Docker-only machine. `Host.access` is metadata, not an authorization grant.
+- A Pod is not a registry Host. `pod-host` models the machine reached with `docker exec`;
+  per-Pod inventory is out of scope.
+- Passwords are accepted only transiently by the add/edit node form and forwarded to
+  `ctx.credentials.set`; the record keeps `credentialRef` only. Shell creation and batch
+  import never accept passwords.
+- Credential writes/deletes are restricted to `env-manager/<environmentId>/<accountId>`
+  (node-add refs use `<hostId>-<username>` as the account id).
+- No arbitrary code in rule templates.
+- No remote execution in V1.
+- No production auto-apply.
+- Registry data is git-ignored.
+- DSH peer packages are not bundled; they resolve from the profile.
+
+## Current Directory Plan
+
+```text
+dsh-env-manager/
+├── AGENTS.md
+├── index.js              # host entry shim (V1)
+├── client.js             # client module
+├── cordis.patch.yml
+├── package.json
+├── tsconfig.json         # added in V1
+├── src/                  # TypeScript host (V1)
+├── lib/                  # build output, git-ignored
+├── locale/
+├── icon.svg
+├── docs/
+├── data/                 # runtime registry data, git-ignored
+└── tests/
+```
+
+## Known Gaps
+
+- The detail view supports create/edit for basic info, nodes, accounts and login records,
+  but deleting a node/account/login from its row is still YAML-only. Clusters can be added
+  and edited; deleting a cluster is YAML-only.
+- Batch import does not accept kind/access/cluster columns; imported nodes are generic VMs
+  and K8s/Pod hosts are edited afterwards.
+- Per-Pod/container inventory is not modeled; a `pod-host` is one machine even when it runs
+  many Pods.
+- Node editing preserves accounts and roles, but there is no bulk edit. Account editing can
+  rotate a password, but private-key and passphrase input remain YAML-only.
+- Database primary/replica/sharding topology is deliberately not modeled in Phase 1: the
+  database plane is a role, and topology detail belongs in node notes until Phase 2.
+- Services, deployments, rule profiles and operation bindings are YAML-only; only
+  environments have structured forms.
+- The `oracle1` environment in the `desktop` profile is demo data created to verify account
+  and login rendering; replace or delete it before real use.
+- Light theme contrast has not been checked yet.
+- Private-key input and key passphrases are still outside the UI; password rotation works
+  through `Edit account`.
+- Deleting an environment does not automatically delete its namespaced credentials; the
+  `credentialUnset` operation exists, but there is no revoke button in the panel yet.
+- Runtime probes V4 (approval from a tool body) and V6 (live credential `describe`)
+  in `api-verification.md` §4 are not exercised yet. Live credential `set`/`unset` via
+  the node form were verified.
+- Memory bridge is a contract and null adapter only; no memory plugin is wired.
+- No cross-process write locking.
+- No operation execution: routing returns the Skill and policy, it does not run them.
+- The panel cannot write production records unless
+  `writePolicy.allowUiProductionWrites` is enabled.
+- No JumpServer/PAM synchronization; account and login observations remain manual/YAML.
+
+## Next Recommended Work
+
+1. **Phase 2** — database topology (primary/replica/sharding) and richer expansion-node
+   modeling, stored without duplicating `hosts[]`.
+2. Batch-import kind/access/cluster columns, and optional Pod/container inventory if
+   operations need per-workload targeting.
+3. Row-level delete for nodes, accounts and login records, plus private-key/passphrase
+   input.
+4. Live probes V4 and V6, then record results in `api-verification.md`.
+5. Optional JumpServer/PAM import adapter for accounts and login observations.
+6. Add a small example registry under `examples/` for first-run demonstration.
+7. P1 memory bridge and operation records.

package/docs/00-project/glossary.md

@@ -0,0 +1,215 @@
+# Glossary
+
+## Environment
+
+One complete network and one configuration page, such as `dev`, `test-a`, `staging` or
+`production`.
+
+Contains the role catalogue, hosts, clusters and access endpoints in one record. An
+environment must declare at least one logical role; the panel seeds management, business,
+database and expansion by default.
+
+## Plane
+
+A role view over an environment's nodes: management, business, database or expansion.
+
+A plane is **not** a separate environment and has no node copies. Opening a plane tab
+filters the environment's single `hosts[]` collection. A node that serves two planes is one
+host with two roles.
+
+## Node
+
+The user-facing name for a host inside an environment. See **Host**.
+
+## Host
+
+A single compute machine inside one environment: a VM, physical machine, Kubernetes node or
+Pod-hosting machine. A Pod is not a Host.
+
+Attributes: hostname, kind, OS, IP, SSH port, roles, command access and a `credentialRef`. A
+host must declare at least one role; it may carry several roles, which is how co-location is
+expressed. It may have zero accounts, or accounts that each carry their own `credentialRef`.
+
+## Node Kind
+
+The machine classification on `Host.kind`: `vm`, `physical`, `k8s-all-in-one`, `k8s-worker`
+or `pod-host`. It describes how the machine participates in the deployment, not which
+logical plane it serves. A missing kind reads as `vm`.
+
+## Command Surface
+
+The command entry points available on a host, recorded in `Host.access`: `ssh`, `kubectl`
+or `docker`. This is capability metadata, not an authorization grant and not a credential.
+
+## Pod Host
+
+A machine running Pods that operators reach with `docker exec`, recorded as
+`Host.kind: pod-host`. It is one Host even when it runs many Pods; individual Pods belong to
+the deployment model, not `hosts[]`.
+
+## Web Login
+
+A management or business console login recorded on `HostAccount`: `loginUrl` is the console
+entry URL, `username` is the login name and `credentialRef` points to the password in the
+DSH credential service. The URL is configuration, never a secret; the password is never
+stored in the environment YAML.
+
+## Cluster
+
+A Kubernetes or Docker cluster inside one environment.
+
+Attributes: kind, optional topology (`all-in-one`, `separate` or `external`), API endpoint,
+namespaces and a `credentialRef`. Kubernetes and Pod-host nodes reference it through
+`Host.clusterRef`.
+
+## Cluster Topology
+
+A descriptive label on `Cluster.topology`:
+
+- `all-in-one` — control plane and worker on the same machine;
+- `separate` — dedicated control plane and worker machines;
+- `external` — a cluster managed outside this environment.
+
+Per-host `Host.kind` is authoritative; topology does not replace it.
+
+## Logical Role
+
+A named function a host can serve, such as `management`, `business`, `database` or
+`extension`.
+
+Hosts and roles are many-to-many via `Host.roles`. Standard role ids are seeded on
+environment creation; custom ids are allowed but must be declared before use.
+
+## Service
+
+A deployable software component described independently of any environment.
+
+Attributes: id, name, aliases, category, Git URL and branch, build tool, artifact name, supported deploy modes and ordered rule profile references.
+
+## Deployment Binding
+
+The relationship "this service runs here, in this runtime mode".
+
+One service may have several bindings in one environment, so `(environmentId, serviceId)` is not unique.
+
+## Runtime Mode
+
+`native`, `docker` or `kubernetes`. Determines which location fields and which log source apply.
+
+## Rule Profile
+
+A reusable set of variables, paths, log sources and class locations.
+
+Referenced by services in order; later profiles win on field conflicts.
+
+## Rule Override
+
+A field-level override carried by an environment or a deployment.
+
+Overriding one field leaves the other fields of the profile intact.
+
+## Rule Layer
+
+One of `global`, `service`, `environment`, `deployment`, in ascending priority.
+
+## Template
+
+A string containing `${...}` references, resolved by interpolation only.
+
+No functions, operators, conditionals or shell execution.
+
+## Provenance
+
+The explanation attached to a resolved value:
+
+- `definedBy` — the layer and profile that supplied the winning template;
+- `inputs` — referenced fields and the layer that supplied each;
+- `shadowed` — lower-priority definitions that lost.
+
+## Derived Value
+
+A value produced by rule resolution. It is not evidence that a file or endpoint exists.
+
+## Verified Value
+
+A value confirmed by an online check. V1 does not produce verified values.
+
+## Service Context
+
+The structured result of resolving an environment, service, deployment, rules and credential status.
+
+Returned by `env_resolve`.
+
+## Operation Binding
+
+A predicate mapping an operation in a given context to a specific Skill, with parameter templates and policy.
+
+## Match Level
+
+How specific a binding is: `deployment`, `environment-service`, `service`, `category-mode`, `global`.
+
+Higher levels win; same-level ties are conflicts.
+
+## Skill Reference
+
+A pointer to a DSH Skill: name, optional expected source and provider.
+
+It is discovery information, not execution authorization.
+
+## Approval Policy
+
+The `requiresApproval` and `allowProduction` fields on a binding.
+
+Write operations default to requiring approval; production defaults to denied.
+
+## Credential Reference
+
+A `credentialRef` string stored in a registry record.
+
+The value behind it lives in the DSH credential service or an external vault and is never returned by this plugin.
+
+## Credential Status
+
+`configured`, `missing` or `unavailable`, obtained from the credential service without reading the value.
+
+## Session Context
+
+The per-session default environment.
+
+Advisory only; it never changes registry records or another session's state.
+
+## Operation Record
+
+A structured, redacted description of a performed operation: scope, operation, Skill reference, timing, outcome, evidence references and summary.
+
+Owned by the memory plugin from P1 onward.
+
+## Evidence Reference
+
+An opaque, sanitized pointer to evidence produced during an operation.
+
+Not the evidence itself.
+
+## Memory Scope
+
+The environment/service/deployment scope attached to a memory query or record.
+
+Prevents a single-environment conclusion from becoming a global rule.
+
+## Memory Bridge
+
+The optional adapter between this plugin and the memory plugin.
+
+Introduces no second store of environment facts and applies nothing automatically.
+
+## Review Queue
+
+The place where candidate rule or Skill changes wait for a human decision.
+
+## Source of Truth
+
+The durable data representation. Here: YAML registry files under the plugin data directory.
+
+## Harness
+
+The project-level control system for AI-assisted development: context rules, constraints, execution and verification policies, and continuity practices.

package/docs/00-project/project-brief.md

@@ -0,0 +1,114 @@
+# Project Brief
+
+## Project Name
+
+DSH Environment Manager (`dsh-env-manager`)
+
+## Positioning
+
+A DSH (DeepSeek Harness) plugin that gives every session a shared, queryable context of enterprise environments, services, deployments, rules and operation-to-Skill bindings.
+
+It is the "where do I work, what am I touching, which rules apply, which Skill runs it, what have we learned" layer for operational Agents.
+
+## Core Value
+
+The project turns:
+
+```text
+scattered environment facts + ad-hoc SSH notes + tribal deployment knowledge
+```
+
+into:
+
+```text
+structured environment registry + service catalog + deployment bindings
++ resolvable rules with provenance + deterministic Skill routing
++ scoped memory references
+```
+
+## Primary Users
+
+- Platform and DevOps engineers
+- SREs and operations staff
+- Backend developers deploying to shared environments
+- AI-assisted development users running DSH sessions
+
+## Main Workflows
+
+### Workflow 1: Resolve Environment Context
+
+```text
+Agent asks: "Where does aicoservice run in test-a?"
+→ look up environment and service
+→ match the deployment binding
+→ resolve layered rules
+→ return a Service Context with provenance
+```
+
+### Workflow 2: Route an Operation to a Skill
+
+```text
+Agent asks: "Redeploy aicoservice in test-a"
+→ resolve the Service Context
+→ match operation bindings by scope
+→ detect conflicts
+→ check Skill availability
+→ return the Skill reference and mapped parameters with policy
+```
+
+### Workflow 3: Configure the Registry
+
+```text
+Engineer adds environment, hosts, clusters and roles
+→ adds services with Git URLs and artifacts
+→ adds deployment bindings
+→ adds rule profiles and overrides
+→ previews resolved paths and bindings
+```
+
+### Workflow 4: Accumulate Experience (P1)
+
+```text
+Operation completes
+→ emit a redacted operation record
+→ query prior observations for the same scope
+→ propose a rule or Skill change for review
+→ never auto-apply
+```
+
+## Core Principles
+
+- File-based registry is the source of truth.
+- Credentials are references; values live elsewhere.
+- Skill routing is explicit, deterministic and conflict-aware.
+- Derived values are labelled as derived; only checks can mark them verified.
+- Conflicting or missing data fails loudly.
+- Memory stores the lesson; this plugin stores the context.
+
+## V1 Scope
+
+Delivered:
+
+1. DSH bundle with Host and Client halves.
+2. File-based registry for environments, services, deployments, rules and operation bindings.
+3. Manual configuration through tools and a minimal Web/Desktop UI.
+4. Layered rule resolution with provenance.
+5. Deterministic operation-to-Skill routing with availability and policy checks.
+6. Read-only tools usable from every session.
+7. Session-scoped default environment.
+
+Deferred:
+
+- Remote execution adapters (SSH, Docker, Kubernetes).
+- Automatic deployment or rollback.
+- Automatic fact extraction from repositories or manifests.
+- Memory bridge implementation (contract only in V1).
+- Automatic rule or Skill evolution.
+
+## Non-goals
+
+- Not a CMDB replacement.
+- Not a secret vault.
+- Not a remote execution engine.
+- Not an unsupervised self-modifying rule system.
+- Not a database-backed platform.