Uh oh!
There was an error while loading. Please reload this page.
feat(intelligence): prepare exact profile activation - #572
Conversation
tangletools
left a comment
There was a problem hiding this comment.
✅ Auto-approved drewstone PR — 7679db6a
This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.
tangletools · auto-approval · reason: drewstone_author · 2026-07-20T02:09:48Z
tangletools
left a comment
There was a problem hiding this comment.
🟡 Value Audit — sound-with-nits
| Verdict | sound-with-nits |
| Concerns | 2 (2 weak-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 204.6s (2 bridge agents) |
| Total | 204.6s |
💰 Value — sound-with-nits
Adds a pure profile-activation prep function that classifies product-owned profiles against a measured transition and returns immutable all-or-none replacements — fills a real gap (knowledge has an executor, profiles didn't), reuses every existing primitive, ships.
- What it does: Adds
prepareAgentImprovementProfileActivation(src/intelligence/profile-activation.ts:65), a synchronous pure function that takes a product's current profiles (by identity) plus a non-empty list of measured activation targets for profile surfaces (prompt/skills/tools/mcp/hooks/subagents), and returns one of four classified outcomes:missing(identity not in the map),already-applied(current - Goals it achieves: Let products apply an approved measured profile change (prompt, skills, tools, mcp, hooks, subagents — the six profile-deliverable surfaces defined in AGENT_IMPROVEMENT_PROFILE_SURFACES) WITHOUT each product reimplementing digest comparison, multi-surface diff folding, or the missing/already-applied/conflict/apply classification. Runtime owns profile-diff semantics (it already owns the digest/diff
- Assessment: Strong fit with the codebase's existing seam. Knowledge already has a sibling helper,
createKnowledgeImprovementActivationExecutor(src/knowledge/activation.ts:38), which produces transition+reconcile callbacks because knowledge writes through Runtime into a durable store. Profiles are different — products own their profile stores — so the appropriate primitive is one step shallower: a pure prep - Better / existing approach: none — this is the right approach. Searched:
grepforprepare,preparation,AgentImprovementActivationTargetPlan,desiredInput,expectedBaseDigest, the four status literals, and the two sibling constructorscreateAgentImprovementActivationResult/createKnowledgeImprovementActivationExecutoracross src/ and tests/. No prior profile-activation preparation function exists; the only s - Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: bridge stream ended without value-audit content
🎯 Usefulness — sound
A pure preparation helper that fills the gap between Runtime's measured profile diffs and a product's owned activation write path; built in the grain of the existing improvement-cycle stack.
- Integration: Exported from src/intelligence/index.ts:170; added to the packed-consumer compile check (scripts/verify-package-exports.mjs:158,218,322) which demonstrates the canonical product-side wiring (prepare → build AgentImprovementActivationOutcome). No internal caller yet — by design: docstring at src/intelligence/profile-activation.ts:60-64 says the caller owns locking/persistence/receipt. Products owni
- Fit with existing patterns: Reuses the established primitives directly: agentImprovementTargetProfileDiffs, applyExactAgentProfileDiff (src/candidate-execution/profile.ts:214), agentImprovementProfileSurfaceDigest, immutableCandidateValue (src/candidate-execution/digest.ts:21). Same canonical-digest discipline, same omitUndefinedObjectFields/parseExactAgentProfile normalization, same 'product owns the write, Runtime owns the
- Real-world viability: Covers the four real outcomes — missing / already-applied / conflict / apply — using exact digest comparisons (src/intelligence/profile-activation.ts:105-110). Post-apply digest verification per target (lines 132-142) catches any drift between desiredInput and desiredDigest. Immutable frozen output via immutableCandidateValue; serializable (verified in tests/profile-activation.test.ts:53). Duplica
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 1
💰 Value Audit
🟡 Non-empty tuple casts repeated inline[maintenance] ``
profile-activation.ts:103, 150, and 156 cast array literals to
[T, ...T[]]viaas. Unavoidable given TS's handling of dynamically-built arrays and the codebase-wide use of non-empty tuple types, but a one-linenonEmptyTuplehelper (or reusing one if it already exists in candidate-execution/digest.ts) would localize the escape hatch. Polish, not a blocker.
🟡 Naming asymmetry vs knowledge executor is not signposted[maintenance] ``
Knowledge uses
createKnowledgeImprovementActivationExecutor(returns transition+reconcile callbacks, src/knowledge/activation.ts:38); profiles now useprepareAgentImprovementProfileActivation(returns data). The asymmetry is correct — different ownership seam — but the JSDoc at profile-activation.ts:60 explains only what the function does, not why profiles get a different shape than knowledge. A one-sentence 'profiles are product-owned, so this returns replacements rather than a transition c
What this audit checks
It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.
| Pass | What it asks |
|---|---|
| Heuristic | Vague title? Whitespace-only or cruft-bearing diff? (content signals only) |
| Duplication | Do added function/class names already exist elsewhere in the repo? |
| Value Audit | What does it do? What goal does it achieve? Is it good? Better architecture or already-exists? |
| Usefulness Audit | Does it integrate and fit? Will it hold up in real use and actually get used? |
Findings are concerns, not blocks — the human reviewer decides what to do with them.
tangletools
left a comment
There was a problem hiding this comment.
✅ Auto-approved drewstone PR — 1a28e464
This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.
tangletools · auto-approval · reason: drewstone_author · 2026-07-20T02:27:41Z
tangletools
left a comment
There was a problem hiding this comment.
🟢 Value Audit — sound
| Verdict | sound |
| Concerns | 0 (none) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 126.1s (2 bridge agents) |
| Total | 126.1s |
💰 Value — sound
Adds a pure preparation primitive that turns approved measured profile transitions into immutable all-or-none replacements for product-owned profile stores; mirrors the existing knowledge-activation seam with the right ownership boundary.
- What it does: Adds prepareAgentImprovementProfileActivation (src/intelligence/profile-activation.ts:67) — a pure function that takes current profiles by identity plus a list of (identity, surface, expectedBaseDigest, desiredDigest, desiredInput) targets, and returns one of four states: 'missing' (some identities absent), 'already-applied' (every current surface digest equals desiredDigest), 'conflict' (some cur
- Goals it achieves: Let products apply approved prompt/skill/tool/mcp/hook/subagent changes to their OWN profile stores without each product reimplementing digest comparison, diff application, conflict detection, or canonical-removal semantics. Runtime owns profile-semantics; the product retains locking, persistence, security policy, and the durable activation receipt. This was inferred from the code, not the PR body
- Assessment: Coherent and tightly in-grain. (1) Reuses existing primitives only: applyExactAgentProfileDiff, omitUndefinedObjectFields, parseExactAgentProfile, agentImprovementTargetProfileDiffs, agentImprovementProfileSurfaceDigest, immutableCandidateValue, and the AgentImprovementActivationTargetPlan/State/Transition types from src/intelligence/activation.ts:34-51. (2) Mirrors the sibling seam at src/knowled
- Better / existing approach: none — this is the right approach. Searched src/ for 'profile.*activation', 'prepare.*Activation', and existing executors; the only sibling is src/knowledge/activation.ts:38, which uses Runtime-owned transition callbacks because knowledge lives in a Runtime-controlled adapter (@tangle-network/agent-knowledge). Forcing profile activation through the same callback shape would require Runtime to take
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: bridge stream ended without value-audit content
🎯 Usefulness — sound
Pure profile-activation prep function — the product-owned-store analog of createKnowledgeImprovementActivationExecutor, built from existing diff primitives with no competing implementation.
- Integration: Exported from src/intelligence/index.ts:170 and exercised by the package-exports compile smoke (scripts/verify-package-exports.mjs:218-241). Reachable from any product that owns an AgentProfile store and consumes executeAgentImprovementActivation's transition callback (src/intelligence/activation.ts:67-69). The first external caller doesn't exist in this repo, which is expected for a substrate pri
- Fit with existing patterns: Fills a real gap. createKnowledgeImprovementActivationExecutor (src/knowledge/activation.ts:38) wires activation for Runtime-owned knowledge stores; until this PR there was no counterpart for product-owned profile stores, forcing every consumer to hand-roll diff assembly (visible in tests/improvement-cycle.test.ts:187-204). Uses established primitives throughout — agentImprovementTargetProfileDiff
- Real-world viability: Pure, synchronous, no I/O or shared state — locking and persistence are explicitly the caller's job per the doc comment at src/intelligence/profile-activation.ts:60-66. Missing/already-applied/conflict/apply are all distinguished statuses matching what assertOutcomeDesiredState (src/intelligence/activation.ts:303-333) verifies. Self-check at src/intelligence/profile-activation.ts:134-144 throws if
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 1
No concerns — sound change, no better or existing approach found. ✅
What this audit checks
It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.
| Pass | What it asks |
|---|---|
| Heuristic | Vague title? Whitespace-only or cruft-bearing diff? (content signals only) |
| Duplication | Do added function/class names already exist elsewhere in the repo? |
| Value Audit | What does it do? What goal does it achieve? Is it good? Better architecture or already-exists? |
| Usefulness Audit | Does it integrate and fit? Will it hold up in real use and actually get used? |
Findings are concerns, not blocks — the human reviewer decides what to do with them.
Uh oh!
There was an error while loading. Please reload this page.
Problem
Products need to apply approved prompt, skill, tool, MCP, hook, and subagent changes to their own AgentProfile stores without copying profile diff semantics into every product.
Solution
Add one pure profile activation preparation function that compares exact measured digests, distinguishes missing/already-applied/conflicting state, and returns immutable serializable all-or-none replacements. Products retain ownership of locking, persistence, security policy, and durable activation receipts.
The package release is prepared as 0.101.0.
Proof