feat(memex): principal attributes memex — schema.org-keyed disclosure pre-fill, multi-agent approval

[toadkicker]

Summary

• Principal attributes memex: principal_attributes SQLite table (prop_name TEXT PRIMARY KEY, value TEXT, last_used) stores per-principal schema.org vocab values across sessions. Three agents asking for schema:departureAirport all share the same stored row — no hardcoded field list.
• Multi-agent approval plan: IntentPlan gains candidates: Vec<AgentCandidate> (up to 3 scored agents). resolve_top_agents(n) replaces single-agent resolution; resolve_agent delegates to it.
• AwaitingApproval block redesign: Agent selector checkboxes (all checked by default, hidden for single agent) + union disclosure form pre-filled from memex via get_principal_attributes Tauri command. Reactive Leptos signals for both.
• canvas_approve_block accepts filled_values and selected_agent_names, stores non-credential values to memex, dispatches handshake to each selected agent with values merged into Phase 3 disclosures via HandshakeParams.extra_disclosures.
• Security: credential params (api_key, token, access_key, etc.) are never persisted to plaintext memex — guarded via CREDENTIAL_PARAM_NAMES. reject_block now requires signedChallenge to prevent gate-leak on rejection. Reserved Phase 3 keys (@type, query) cannot be overwritten by extra_disclosures.
• CI fixes: clippy::manual_split_once in pap-agents, rustfmt pass, removed "+ Note" button, Sources tab, and broken "< Canvas" settings link.

Test plan

• cargo test --workspace — 1,209+ tests, all pass
• just check-wasm / WASM compile check — clean
• Clippy clean (cargo clippy -D warnings)
• cargo fmt --check passes

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

• Removes the broken Skyscanner/RapidAPI endpoint from kayak_flights.toml (URL parameters {from}, {to}, {date} were never substituted by the handler, only {query} is) and converts the agent to LLM-only mode; however, the new llm_instructions value itself contains {query} which is also never substituted, leaving a literal placeholder in the LLM system prompt on every call.
• Changes the non-2xx HTTP response path in dynamic_handler.rs to fall through to the LLM instead of returning a TransportError::ServerError, which is the correct fix for the "Failed at phase 4" user-facing error; the response body is dropped unread which may affect connection pool reuse.
• provider = \"DuckDuckGo\" in the updated TOML is inaccurate since no DuckDuckGo endpoint is used.

Confidence Score: 3/5

The core handler fix is correct but the new TOML introduces a runtime defect (unsubstituted {query} placeholder in the LLM system prompt) that should be resolved before merging.

One P1 defect (literal {query} in llm_instructions is never replaced, sending a malformed system prompt to the LLM on every flight query) combined with two P2 issues pulls the score below the P1 ceiling of 4.

crates/pap-agents/catalog/travel/kayak_flights.toml — the llm_instructions {query} substitution bug and the misleading provider field both need to be addressed.

Important Files Changed

Filename	Overview
crates/pap-agents/src/dynamic_handler.rs	Non-2xx branch now silently falls through to LLM instead of returning an error; let _ = status; is a no-op and the response body is dropped unread, which may hurt connection pooling.
crates/pap-agents/catalog/travel/kayak_flights.toml	Broken Skyscanner endpoint removed and agent converted to LLM-only; introduces a {query} placeholder in llm_instructions that is never substituted at runtime, and an incorrect provider = "DuckDuckGo" value.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[User query routed to DynamicAgentHandler] --> B{Endpoint configured?}
    B -- Yes --> C[Build & send HTTP request]
    B -- No --> G
    C --> D{HTTP response}
    D -- 2xx --> E{Extract JSON via response_mapping / jsonpath}
    E -- data found --> F[Return schema.org object]
    E -- no data --> G
    D -- "non-2xx (OLD: return ServerError)" --> G
    D -- network error --> G
    G[Call LLM with llm_instructions + query] --> H{agent returns pap:IntentClassification?}
    H -- Yes --> I[Parse & return JSON]
    H -- No --> J[Return schema:Answer]

    style D fill:#f9c,stroke:#c66
    style G fill:#cfc,stroke:#6a6

Loading

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
crates/pap-agents/catalog/travel/kayak_flights.toml:11
**`{query}` in `llm_instructions` is never substituted**

`dynamic_handler.rs` only calls `endpoint.url_template.replace("{query}", &query)` and the body-template equivalent; it passes `self.def.llm_instructions` to `client.complete()` verbatim (line 235). The new `llm_instructions` value deliberately embeds `{query}` expecting runtime substitution, but no substitution happens — the LLM system prompt will always contain the literal string `{query}` instead of the actual flight search term.

The user query is still forwarded as the second argument to `complete`, so results won't be completely wrong, but the system-prompt instruction "The user is searching for: {query}" is always broken, sending a confusing placeholder to the model on every call.

### Issue 2 of 3
crates/pap-agents/catalog/travel/kayak_flights.toml:4
**`provider` field is misleading**

`provider = "DuckDuckGo"` is set, but no DuckDuckGo endpoint exists — this is a pure LLM-only agent. The `provider` field in other catalog agents identifies the actual data source (e.g. the old `"KAYAK / Flights API"`); setting it to an unrelated third party may confuse both the UI and future maintainers. A value like `"LLM"` or simply the actual LLM backend name would be more accurate.

### Issue 3 of 3
crates/pap-agents/src/dynamic_handler.rs:223
**Unconsumed response body may prevent connection reuse**

`let _ = status;` is a no-op — `status` was already bound on line 189 and copied (it's `Copy`). More importantly, dropping `resp` here without reading its body prevents `reqwest`'s blocking client from returning the underlying TCP connection to the pool, so every non-2xx API response forces a new connection on the next call. Consider draining the body with `let _ = resp.bytes();` before falling through to keep connection pooling working.

_{Reviews (1): Last reviewed commit: "fix(agents): fall through to LLM on non-..." | Re-trigger Greptile}

[greptile-apps]

{query} in llm_instructions is never substituted

dynamic_handler.rs only calls endpoint.url_template.replace("{query}", &query) and the body-template equivalent; it passes self.def.llm_instructions to client.complete() verbatim (line 235). The new llm_instructions value deliberately embeds {query} expecting runtime substitution, but no substitution happens — the LLM system prompt will always contain the literal string {query} instead of the actual flight search term.

The user query is still forwarded as the second argument to complete, so results won't be completely wrong, but the system-prompt instruction "The user is searching for: {query}" is always broken, sending a confusing placeholder to the model on every call.

Prompt To Fix With AI

This is a comment left during a code review.
Path: crates/pap-agents/catalog/travel/kayak_flights.toml
Line: 11

Comment:
**`{query}` in `llm_instructions` is never substituted**

`dynamic_handler.rs` only calls `endpoint.url_template.replace("{query}", &query)` and the body-template equivalent; it passes `self.def.llm_instructions` to `client.complete()` verbatim (line 235). The new `llm_instructions` value deliberately embeds `{query}` expecting runtime substitution, but no substitution happens — the LLM system prompt will always contain the literal string `{query}` instead of the actual flight search term.

The user query is still forwarded as the second argument to `complete`, so results won't be completely wrong, but the system-prompt instruction "The user is searching for: {query}" is always broken, sending a confusing placeholder to the model on every call.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

provider field is misleading

provider = "DuckDuckGo" is set, but no DuckDuckGo endpoint exists — this is a pure LLM-only agent. The provider field in other catalog agents identifies the actual data source (e.g. the old "KAYAK / Flights API"); setting it to an unrelated third party may confuse both the UI and future maintainers. A value like "LLM" or simply the actual LLM backend name would be more accurate.

Prompt To Fix With AI

This is a comment left during a code review.
Path: crates/pap-agents/catalog/travel/kayak_flights.toml
Line: 4

Comment:
**`provider` field is misleading**

`provider = "DuckDuckGo"` is set, but no DuckDuckGo endpoint exists — this is a pure LLM-only agent. The `provider` field in other catalog agents identifies the actual data source (e.g. the old `"KAYAK / Flights API"`); setting it to an unrelated third party may confuse both the UI and future maintainers. A value like `"LLM"` or simply the actual LLM backend name would be more accurate.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Unconsumed response body may prevent connection reuse

let _ = status; is a no-op — status was already bound on line 189 and copied (it's Copy). More importantly, dropping resp here without reading its body prevents reqwest's blocking client from returning the underlying TCP connection to the pool, so every non-2xx API response forces a new connection on the next call. Consider draining the body with let _ = resp.bytes(); before falling through to keep connection pooling working.

Prompt To Fix With AI

This is a comment left during a code review.
Path: crates/pap-agents/src/dynamic_handler.rs
Line: 223

Comment:
**Unconsumed response body may prevent connection reuse**

`let _ = status;` is a no-op — `status` was already bound on line 189 and copied (it's `Copy`). More importantly, dropping `resp` here without reading its body prevents `reqwest`'s blocking client from returning the underlying TCP connection to the pool, so every non-2xx API response forces a new connection on the next call. Consider draining the body with `let _ = resp.bytes();` before falling through to keep connection pooling working.

How can I resolve this? If you propose a fix, please make it concise.

[github-actions]

Benchmark Regression Report

PAP Protocol Benchmark Regression Check
========================================
Baseline: .bench-baseline/baseline.json
Threshold: 55%

  ed25519_keypair_generation                19.6 µs  (baseline: 19.6 µs, +0.1%)  [ok]
  did_key_derivation                         1.5 µs  (baseline: 1.5 µs, -0.3%)  [ok]
  mandate_create_sign                       24.0 µs  (baseline: 23.8 µs, +0.8%)  [ok]
  mandate_chain_verify_depth3              164.6 µs  (baseline: 144.8 µs, +13.7%)  [ok]
  sd_jwt_issue_5claims                      27.8 µs  (baseline: 27.8 µs, +0.3%)  [ok]
  sd_jwt_verify_disclose_3of5               55.3 µs  (baseline: 50.2 µs, +10.0%)  [ok]
  session_open_full_lifecycle              114.1 µs  (baseline: 108.3 µs, +5.3%)  [ok]
  receipt_create_cosign                     48.0 µs  (baseline: 48.0 µs, +0.0%)  [ok]
  federation_announce_local                 61.7 µs  (baseline: 66.6 µs, -7.3%)  [ok]


P99 Tail-Latency Check
----------------------
Results: target/p99_results.json
Threshold: 50%

  session_open_full_lifecycle(p99)         132.2 µs  (baseline: 500.0 µs, -73.5%)  [ok]
  mandate_chain_verify_depth3(p99)         159.9 µs  (baseline: 480.0 µs, -66.6%)  [ok]
  receipt_create_cosign(p99)                57.9 µs  (baseline: 210.0 µs, -72.4%)  [ok]

All benchmarks within 55% of baseline.

_{Threshold: 10% regression vs baseline from main}