Feat/agentteam productization

Makefile

@@ -50,7 +50,7 @@ unit: ## Run Go unit tests
 vet: ## Run go vet static analysis
 	go vet ./...
 
-harness-validate: ## Validate harness loop manifests and declared asset paths
+harness-validate: ## Validate harness event packages
 	bash scripts/validate_harness_loops.sh
 
 harness-docs-check: ## Check bilingual harness doc heading sync

README.md

@@ -355,8 +355,7 @@ Different agents/processes can use different stores via the `MNEMON_STORE` envir
 
 **How do I customize the behavior?**
 Edit the generated guideline (`~/.mnemon/prompt/guide.md` in current setup
-flows) or use the installable [memory loop GUIDE](harness/internal/assets/loops/memory/GUIDE.md)
-as the source. The skill file should stay focused on command syntax.
+flows). Skill files should stay focused on command syntax.
 
 **What is sub-agent delegation?**
 Sub-agent delegation is optional. When a runtime supports it, the main agent can
@@ -396,8 +395,6 @@ See [Development and Deployment](docs/DEPLOYMENT.md) for Docker, Compose, Ollama
 ## Documentation
 
 - [Mnemon Harness Beta](harness/README.md) — experimental host-agent lifecycle state
-- [Memory Loop Harness](harness/internal/assets/loops/memory/README.md) — installable memory loop assets
-- [Skill Loop Harness](harness/internal/assets/loops/skill/README.md) — installable skill loop assets
 - [Design & Architecture](docs/DESIGN.md) — current engine architecture, algorithms, integration design
 - [Usage & Reference](docs/USAGE.md) — CLI commands, embedding support, architecture overview
 - [Memory Import Guide](docs/IMPORT.md) — schema and LLM prompt for importing historical chats

docs/DESIGN.md

@@ -47,7 +47,7 @@ Markdown-installable runtime integration: `SKILL.md`, `INSTALL.md`, `GUIDELINE.m
 
 ### [Self-Evolution Harness](harness/README.md)
 
-The formal modular harness docs for agent-agnostic installation, memory loop, skill loop, and future attachable evolution modules.
+The formal modular harness docs for agent-agnostic installation, Agent Integration, event packages, and future attachable evolution modules.
 
 ### [8. Design Decisions & Future Direction](design/08-decisions.md)
 

docs/harness/QUICKSTART.md

@@ -14,8 +14,8 @@ Goal: stand up Local Mnemon, observe one candidate, and see it admitted as a
 governed decision on the Control Tower.
 
 ```sh
-# 1. install the integration for your host + a memory loop
-mnemon-harness setup --host codex --loop memory \
+# 1. install the integration for your host
+mnemon-harness setup --host codex \
   --principal codex@project --control-url http://127.0.0.1:8801
 
 # 2. start Local Mnemon (the local governance daemon)
@@ -25,8 +25,8 @@ mnemon-harness local run &
 mnemon-harness control observe \
   --addr http://127.0.0.1:8801 --principal codex@project \
   --token-file .mnemon/harness/channel/credentials/codex-project.token \
-  --type memory.write_candidate.observed --external-id q1 \
-  --payload '{"content":"my first governed memory","source":"user","confidence":"high"}'
+  --type progress_digest.write_candidate.observed --external-id q1 \
+  --payload '{"summary":"my first governed event"}'
 # -> observed seq=1 dup=false ticked=true
 
 # 4. stop the daemon, then read the Control Tower (it needs exclusive store access)
@@ -39,7 +39,7 @@ to its proposer:
 
 ```
 # LEDGER
-  dec_… by codex@project -> memory
+  dec_… by codex@project -> progress_digest
 ```
 
 That is the whole point: a candidate became a **governed, attributed decision**
@@ -53,7 +53,7 @@ Goal: declare a new event kind as a loop package and watch it govern, with no
 code — a capability is **data that SELECTS from a closed catalog** of validators
 and renderers, never new behavior.
 
-Start from a working install (Path A, or `setup --host codex --loop memory …`).
+Start from a working install (Path A, or `setup --host codex …`).
 
 ```sh
 # 1. drop a loop package: .mnemon/loops/<name>/capability.json
@@ -81,7 +81,7 @@ JSON
 #          allowed_observed_types: "note.write_candidate.observed"
 #          subscription_scope:     {"kind":"note","id":"project"}
 
-# 3. run + observe your new kind — it governs through the SAME path as the built-ins
+# 3. run + observe your new kind — it governs through the SAME path as embedded descriptors
 mnemon-harness local run &
 mnemon-harness control observe \
   --addr http://127.0.0.1:8803 --principal codex@project \

docs/harness/README.md

@@ -4,14 +4,14 @@
 assets and connecting them to a local Mnemon service.
 
 Stable Mnemon remains the memory CLI. The harness is source-build only, has no
-compatibility guarantee, and is currently scoped to memory and skill
-integration.
+compatibility guarantee, and is currently scoped to Agent Integration, Local
+Mnemon, standard event packages, and Remote Workspace sync.
 
 ## 1. Product Surface
 
 The user-facing command surface is intentionally small:
 
-- `setup`: install memory and skill Agent Integration assets.
+- `setup`: install Agent Integration shim assets.
 - `local`: run or inspect Local Mnemon.
 - `status`: show Agent Integration, Local Mnemon, and Remote Workspace state.
 - `sync`: connect Local Mnemon to a Remote Workspace.
@@ -21,9 +21,9 @@ contract.
 
 ## 2. Current Scope
 
-The beta supports Codex and Claude Code projections for the memory and skill
-loops. Projected host directories such as `.codex/` and `.claude/` are generated
-surfaces. Local state lives under `.mnemon/harness/`.
+The beta supports Codex and Claude Code projections. Projected host directories
+such as `.codex/` and `.claude/` are generated surfaces. Local state lives under
+`.mnemon/harness/`.
 
 The current beta does not promise production readiness, automatic apply,
 multi-agent governance, broad organization scope, or a general evaluation
@@ -45,10 +45,10 @@ go build -o mnemon .
 go build -o mnemon-harness ./harness/cmd/mnemon-harness
 ```
 
-Install memory and skill integration for a project:
+Install Agent Integration for a project:
 
 ```sh
-./mnemon-harness setup --host codex --loop memory --loop skill --project-root .
+./mnemon-harness setup --host codex --project-root .
 ./mnemon-harness local run
 ./mnemon-harness status
 ```

docs/harness/USAGE.md

@@ -9,21 +9,21 @@ go build -o mnemon-harness ./harness/cmd/mnemon-harness
 
 ## 1. Install Agent Integration
 
-Install memory and skill integration into the current project:
+Install Agent Integration into the current project:
 
 ```sh
-./mnemon-harness setup --host codex --loop memory --loop skill --project-root .
+./mnemon-harness setup --host codex --project-root .
 ```
 
 Use `--dry-run` to preview file changes:
 
 ```sh
-./mnemon-harness setup --host codex --loop memory --loop skill --project-root . --dry-run
+./mnemon-harness setup --host codex --project-root . --dry-run
 ```
 
 ## 2. Run Local Mnemon
 
-Start the local service used by the projected host skills:
+Start the local service used by the host integration:
 
 ```sh
 ./mnemon-harness local run

docs/harness/capability-spec-v1.md

@@ -1,7 +1,7 @@
 # Capability Spec v1 (frozen)
 
 > Superseded by `capability-spec-v2.md` (P2, 2026-06-12). v2 formalizes the type grammar as a
-> closed table (reserving the system-derived `<kind>.remote_commit.observed` form), defines how a
+> closed table (reserving the system-derived `<kind>.remote_synced_event.observed` form), defines how a
 > declared kind's required fields derive, and — per the R1 no-forward-compat revision channel —
 > moves the KindCatalog membership check to the assembly-time declared set. This document remains
 > the v1 record; the live compile path follows v2.
@@ -55,7 +55,7 @@ directory ≡ name ≡ kind as well, so the package directory IS the event famil
 | member | params | deny message |
 |---|---|---|
 | `required` | `missing_style: empty\|missing` | `empty <field>` / `missing <field>` |
-| `format:skill-id` | — | `invalid <field>` (lowercase a-z0-9 dash) |
+| `format:identifier` | — | `invalid <field>` (lowercase a-z0-9 dash) |
 | `enum` | `values: a\|b\|c`, `message` | `<message>` |
 | `default` | `value` | — (fills trimmed-empty) |
 | `default-from` | `field` (declared EARLIER) | — (fills from processed field) |
@@ -68,7 +68,7 @@ directory ≡ name ≡ kind as well, so the package directory IS the event famil
 
 | member | params | output |
 |---|---|---|
-| `memory-entry-list` | — | `content` = the memory entry-list markdown |
+| `entry-list` | — | `content` = the generic entry-list markdown |
 | `bullet-list` | `title`, `field` (declared) | `content` = title + `"- "+item[field]` lines |
 
 `static` is a literal field map. A member that evaluates user content as a template is FORBIDDEN
@@ -77,7 +77,7 @@ vocabulary — item values are joined, never executed. Render-produced keys must
 
 ## FromSpec fail-closed checks
 
-schema_version == 1 · non-empty core fields · resource_kind ∈ KindCatalog · no duplicate fields ·
+schema_version == 1 · non-empty core fields · resource_kind not reserved · no duplicate fields ·
 member existence · exact param key sets (missing/unknown params rejected) · `default-from` only
 backward references · `list:strings` exclusivity · render collision guards. Cross-spec (loader):
 duplicate capability names / observed types / proposed types rejected.
@@ -94,8 +94,8 @@ package path) refuses Local Mnemon boot. Two deliberate differences from embedde
 messages, `default` validator values — free prose that lands verbatim in items when the host
 omits the field — render `static` values, and the bullet-list `title`) are scanned by the
 secret/prompt-injection scanners; IDENTIFIERS (field names, `items_field`, render `static` keys)
-are pattern-locked to `^[a-z][a-z0-9_-]*$` (underscore allowed — the builtin `skill_id` and
-`items_field` shapes carry it); the spec `name` is pattern-locked via directory == name (== kind)
+are pattern-locked to `^[a-z][a-z0-9_-]*$` (underscore allowed for descriptor field names such as
+`items_field`); the spec `name` is pattern-locked via directory == name (== kind)
 — because embedded spec text is reviewed code pinned by golden parity (TestSpecGoldens) while
 external spec text is untrusted input; (b) the merge rejects shadowing on FOUR axes (name,
 observed type, proposed type, resource kind) — an external spec can never displace or impersonate

docs/harness/capability-spec-v2.md

@@ -15,7 +15,7 @@
 >    assembled one). See `loop-package-v2.md` and the PD2 declared-kind mechanism.
 
 The DATA form of a capability: `<name>/capability.json` (external) or
-`assets/capabilities/<name>.json` (first-party), compiled by `capability.FromSpec` against the
+`assets/capabilities/<name>.json` (embedded), compiled by `capability.FromSpec` against the
 CLOSED validator and render catalogs. A spec only ever SELECTS compiled members and COMPOSES
 closed validators — it never defines behavior (define≠select); everything unknown fails closed.
 
@@ -34,12 +34,12 @@ just free text).
 |---|---|---|
 | `<kind>.write_candidate.observed` | `observed_type` — the host's write candidate | yes |
 | `<kind>.write.proposed` | `proposed_type` — the rule's proposal (reconciler consumes only `*.proposed`) | yes |
-| `<kind>.remote_commit.observed` | sync-import observation the platform mints | **no — system-derived** |
+| `<kind>.remote_synced_event.observed` | sync-import observation the platform mints | **no — system-derived** |
 
 A spec that declares a system-derived form is rejected by name ("system-derived, not
 spec-declarable"). New event families are added as a table ROW, not by reshaping the compile path
 — this is the G7 extension point that lets P3's coordination/model-event families exist without
-the grammar fighting them. The `remote_commit` form is the sync-import wire (`sync-abi-v2.md` §6);
+the grammar fighting them. The `remote_synced_event` form is the sync-import wire (`sync-abi-v2.md` §6);
 its rule and producer landed in PD6 (descriptor-derived import dispatch + the produce surface).
 
 ## Declared kind + required fields
@@ -55,11 +55,10 @@ kind's kernel-required fields DERIVE from the spec rather than a parallel hand-w
 > fields are selected from — a kind can never require a field its writes do not carry. A spec's
 > optional `required` array SELECTS a subset of those produced keys; omitted, every produced key is
 > required. Because the capability emits its full header on every propose, the produced keys are
-> exactly the fields every write carries, so the default reproduces the v1 hand-written
-> `DefaultSchemaGuard` lines (memory render content → `{content}`; skill render static
-> `{"name":"project"}` → `{name}`), and `required` narrows it where v1 hand-picked a subset (goal
-> renders `{content, statement}` but required only `{statement}` → declares `"required":
-> ["statement"]`). FromSpec rejects a `required` entry the render does not produce. The lockstep
+> exactly the fields every write carries. `required` narrows that set where a spec renders multiple
+> header fields but only some should be kernel-required (for example a kind rendering
+> `{content, statement}` but declaring `"required": ["statement"]`). FromSpec rejects a `required`
+> entry the render does not produce. The lockstep
 > test becomes: governance kinds stay bidirectionally pinned in code; user kinds have a single
 > source — the capability spec, read through the assembled catalog.
 
@@ -72,8 +71,8 @@ the wiring is in the runtime.
 
 A declared kind may NOT: be a governance kind (`lease`/`budget`/`receipt`/`coordination`); be in the
 reserved `mnemon` namespace (the exact kind `mnemon` or a `mnemon_` prefix — the kind grammar
-`^[a-z][a-z0-9_]*$` admits no dot, so the namespace separator is `_`); collide with a first-party
-event family whose diagnostics share a domain (`sync`, `session`, `remote`); or shadow any
+`^[a-z][a-z0-9_]*$` admits no dot, so the namespace separator is `_`); collide with a reserved
+system event family whose diagnostics share a domain (`sync`, `session`, `remote`); or shadow any
 already-loaded capability on the four axes (name, observed type, proposed type, resource kind). External package text remains untrusted input —
 values scanned by the secret/prompt-injection scanners, identifiers pattern-locked — exactly as in
 v1's external-loader section.

docs/harness/loop-package-v1.md

@@ -117,17 +117,17 @@ document maps to an enforcing fault class:
 | strict spec decode | class ① bad JSON / trailing data / unknown keys (decodeSpec); ② unknown vocabulary, ③ kind outside KindCatalog (FromSpec) |
 | no shadowing | class ④ four-axis merge rejection — name, observed type, proposed type, resource kind — external may not claim what embedded claims; ⑤ two externals may not collide either (incl. sharing a kind) |
 | kernel-satisfiable | class ⑦ load-time SchemaGuard lockstep: statically derived header keys (static ∪ content ∪ items_field ∪ updated_by) must cover the kind's required fields |
-| untrusted spec surfaces | class ⑧, EXTERNAL ONLY, two halves. VALUES → scanned by the secret + prompt-injection scanners: enum deny messages, `default` validator values, render static values, the bullet-list title. IDENTIFIERS → pattern-locked to `^[a-z][a-z0-9_-]*$` (underscore allowed; the builtin `skill_id`/`items_field` shapes carry it): field names, `items_field`, render static keys. The spec `name` is pattern-locked via directory == name (class ⑨) and scanned as belt-and-braces |
+| untrusted spec surfaces | class ⑧, EXTERNAL ONLY, two halves. VALUES → scanned by the secret + prompt-injection scanners: enum deny messages, `default` validator values, render static values, the bullet-list title. IDENTIFIERS → pattern-locked to `^[a-z][a-z0-9_-]*$` (underscore allowed for descriptor field names such as `items_field`): field names, `items_field`, render static keys. The spec `name` is pattern-locked via directory == name (class ⑨) and scanned as belt-and-braces |
 | no kernel-internal kinds | class ⑪: `lease`/`budget`/`receipt`/`coordination` are deny-listed for external claim |
 | no symlinks | class ⑩: a symlinked external root, package dir, or capability.json is rejected by ResolveCatalog's lstat screening on the real path |
 
 A bad package REFUSES `local run` boot — the directory's presence is a contract, not a hint;
 `local run --ignore-external` is the operator escape hatch (embedded-only catalog, each ignored
 package named on stderr). `loop validate` reports each loadable package as
-`external capability <name>: OK` and goes red on any loader failure. Sync-import stays
-memory/skill-only — narrower than Builtins: pushes are kind-agnostic, but the puller imports only
-memory and skill commits and drops every other kind; external capabilities have no remote
-producer in v1.
+`external capability <name>: OK` and goes red on any loader failure. In v1, sync-import stayed
+limited to a fixed embedded set — narrower than the catalog: pushes were kind-agnostic, but the
+puller imported only that fixed set and dropped every other kind; external capabilities had no
+remote producer in v1. This is superseded by `sync-abi-v2.md`.
 
 ## Migration provenance
 

docs/harness/loop-package-v2.md

@@ -17,7 +17,7 @@
 >    path-miss).
 > 3. Prose assets (GUIDE.md, SKILL.md) carry a documentation-grade injection scan, not the
 >    content-grade secret scan (a legitimate GUIDE may honestly discuss "private keys").
-> 4. The v1 "sync-import stays memory/skill-only … external capabilities have no remote producer"
+> 4. The v1 "sync-import stays fixed-embedded-only … external capabilities have no remote producer"
 >    sentence is superseded by `sync-abi-v2.md` (PD6, descriptor-derived sync).
 
 ## Package contents (external packages, v2)