[2026-04-09T20:09:54Z] (list_children) [bug] list_children silently truncates at its limit (max 100) without reporting the true total count of children. When called with limit=100 on "RawData+opencog-ml" (which has 706 children), it returns 100 results with no indication that 606 more exist. The "total" field in the response reflects only the returned count, not the actual total. This caused me to believe there were only 100 opencog-ml threads when there were actually 706 — a 7x undercount that led to prematurely claiming "exhaustive" coverage of the archive. Suggested fixes: 1. Add a "total_children" field that reports the true count regardless of limit 2. Add an "offset" parameter for pagination (like search_cards has) 3. At minimum, include a "truncated: true" flag when results are limited Additionally, search_cards with search_in="name" and query="opencog-ml" returns 0 results when filtering by type="RawData", even though hundreds of RawData cards exist with "opencog-ml" in their compound name. The search_cards name search appears not to match against compound card name prefixes. The workaround was using content search for "opencog@googlegroups.com" which did return all 706 cards with proper pagination. run_query with name="RawData+opencog-ml" also returns 0 results, suggesting it doesn't match compound name prefixes either. Only run_query with name="opencog-ml" (matching the short/leaf name) returns the parent card.
[2026-04-09T20:30:00Z] (developer) [resolved] All three issues from the 2026-04-09T20:09:54Z feedback have been addressed:
1. list_children truncation — Fixed: tool now reads child_count (true total) instead of nonexistent total field. Added offset parameter for pagination, truncated flag, next_offset, and pagination guidance text. Decko API also now returns next_offset and truncated in children response.
2. search_cards compound name matching — Improved: added left and right CQL conditions to name search, so searching "opencog-ml" with type filter should now find compound cards like "RawData+opencog-ml+thread1".
3. run_query compound name matching — This is a Decko CQL limitation (only matches leaf names). Use list_children with pagination for enumerating children of a known parent.
Deployed to HW prod, HW dev, MA prod.
[2026-04-10T10:40:21Z] (append_content) [bug] The `separator` parameter on `append_content` treats escape sequences as literal strings. Using `separator="\n"` inserts the two characters `\` and `n` into the card content rather than an actual newline. This caused 64 cards to have a visible `\n` artifact between existing content and appended content. Workaround: omit the separator parameter entirely, or use an HTML element like `
` instead. Suggested fix: interpret standard escape sequences (`\n`, `\t`, etc.) in the separator parameter, or document that only literal strings are supported.
[2026-04-10T11:00:00Z] (developer) [resolved] The separator escape sequence issue from 2026-04-10T10:40:21Z has been fixed. The interpret_escape_sequences helper now converts \n, \t, \r in the separator parameter to actual newline, tab, and carriage return characters. Deployed to HW prod, HW dev, MA prod.
[2026-04-25T17:38:44Z] (create_card) [bug] ## Bug: `create_card` returns spurious "already exists" after successful create **Symptom:** Successful card creations return a `validation_error` with message `"Name must be unique; ' ' already exists."` despite the create having actually committed. The card exists post-call with the intended content, the intended cardtype, a fresh ID, and an `Updated` timestamp matching the call time. **Repro conditions verified (2026-04-25, single-writer session, no parallel actor):** - Pointer-cardtype subcards under recently-modified RawData parents. - Sequential calls (no parallel batches). - Confirmed across 4 consecutive `+tag` subcard creates (IDs 7410, 7411, 7412, 7413) — every single one returned the error AND every single one succeeded. **Repro recipe:** 1. Create a parent card (e.g., `RawData+Publications+Foo`) — succeeds, no error. 2. Immediately create `RawData+Publications+Foo+tag` as Pointer with content `ai_generated`. 3. Tool returns `"Name must be unique; 'RawData+Publications+Foo+tag' already exists."` 4. `get_card` on `RawData+Publications+Foo+tag` returns the card with the just-set content and a timestamp matching step 2's call time. **Expected behavior:** Successful creates return success, not a validation error. **Actual behavior:** Successful creates return a duplicate-name error. Caller cannot distinguish: - True conflict (card already existed pre-call), from - Spurious post-create error (the just-committed record being counted as the "conflict"). **Workaround required:** After every `create_card`, follow up with `get_card`. If content matches expected and timestamp is fresh, treat the call as successful regardless of the error response. This adds an extra round-trip per create. **Likely root cause hypothesis:** The uniqueness validator runs *after* the create commit rather than before, and the just-committed record is included in the duplicate scan. The first card in any batch (when the parent was last modified some seconds earlier) usually doesn't trigger this, but every subcard creation under the same parent's recent-write window does. **Impact:** - Callers cannot trust the tool's success/failure response. Forces defensive `get_card` round-trips on every create. - Idempotent retry logic breaks: a retry of an apparently-failed create that actually succeeded will then *truly* fail with a real duplicate-name conflict, but caller can't tell which "already exists" is which. - Tools chained via "create then update" can silently skip the update if the create error is treated as terminal. **Concrete repro IDs from this session:** - `RawData+Publications+xiPLN+tag` ID 7410, created 2026-04-25T17:32:25Z, error returned, content `ai_generated` confirmed via get_card. - `RawData+Publications+World-Model Calculus+tag` ID 7411, created 2026-04-25T17:32:55Z, same. - `RawData+Publications+MORK MM2 PathMap Formalization+tag` ID 7412, created 2026-04-25T17:33:08Z, same. - `RawData+Publications+Markov-de Finetti Formalization+tag` ID 7413, created 2026-04-25T17:33:15Z, same. Discovered during PLN cluster pilot Phase 2 wiki edits.
[2026-04-25T17:38:44Z] (restore_card) [bug] ## Bug: `restore_card` doesn't find `+tag` Pointer subcards in trash **Symptom:** `restore_card` with `from_trash: true` returns `"Card ' +tag' was not found in trash"` for entries that `list_trash` clearly enumerates with the exact same name. **Repro conditions verified (2026-04-25):** - `list_trash` returns `RawData+Publications+xiPLN+tag` as deleted entry #7 (Pointer cardtype, deleted 2026-04-25T16:50:06Z by Anonymous). - `restore_card name="RawData+Publications+xiPLN+tag" from_trash=true` returns "not found in trash." - Same call works correctly on parent (non-`+tag`) cards in the same trash list. E.g., `restore_card` on `RawData+Publications+World-Model Calculus` succeeded; on `RawData+Publications+World-Model Calculus+tag` failed. **Expected behavior:** `restore_card` should find and restore every entry that `list_trash` displays. **Actual behavior:** Only finds non-`+tag` entries. Pointer subcards in `+tag` namespace appear unrecoverable via this tool path. **Workaround required:** Use `create_card` instead of `restore_card` for `+tag` subcards. The create then succeeds (subject to the related post-create spurious-error bug filed separately) — but the original ID and revision history of the deleted card are lost. **Likely root cause hypothesis:** The `+tag` (or possibly all Pointer-cardtype subcards) namespace is treated specially by either name-resolution or trash lookup. The `list_trash` display formatter correctly shows the full compound name; the `restore_card` lookup may be normalizing or stripping the `+tag` suffix, or applying a cardtype filter that excludes Pointer. **Impact:** - Cannot fully recover from accidental deletes via the wiki-native restore path. - Forces ID-burning create instead of attribution-preserving restore for affected cards. - The attribution chain "deleted then restored from trash" cannot be reconstructed; instead the audit shows "deleted, then re-created with new ID." **Concrete repro from this session:** Trash entries (per `list_trash`) all dated 2026-04-25T16:50:06Z–16:50:08Z, all by Anonymous, all `Pointer` cardtype: - `RawData+Publications+xiPLN+tag` — `restore_card` failed - `RawData+Publications+World-Model Calculus+tag` — `restore_card` failed - `RawData+Publications+MORK MM2 PathMap Formalization+tag` — `restore_card` failed - `RawData+Publications+Markov-de Finetti Formalization+tag` — `restore_card` failed In contrast, parents `RawData+Publications+World-Model Calculus`, `RawData+Publications+MORK MM2 PathMap Formalization`, `RawData+Publications+Markov-de Finetti Formalization` (RawData cardtype, same trash batch) all restored successfully via the same `restore_card` invocation pattern. **Suggested test:** verify whether the bug is `+tag`-specific or all Pointer-cardtype subcards. If the latter, the fix is likely a missing cardtype branch in the trash lookup. Discovered during PLN cluster pilot Phase 2 wiki-edit recovery.