| name | bootstrap-memory-ingest-cloud |
| description | Write structured memory entries to the Cloud workspace via gaai_memory.store MCP tool with source='bootstrap'. Loops over entries from bootstrap-llm-synthesis, calls the tool per entry, collects success/fail counts. Used as Stage 5 of the /gaai:bootstrap pipeline (Cloud path only). |
| license | ELv2 |
| compatibility | Requires GAAI Cloud MCP connection with bootstrap_status=in_progress in the target workspace |
| metadata | {"author":"gaai-framework","version":"1.0","category":"cross","track":"cross-cutting","id":"SKILL-BOOTSTRAP-MEMORY-INGEST-CLOUD-001","updated_at":"2026-05-01T00:00:00.000Z","status":"stable"} |
| inputs | ["synthesis_result"] |
| outputs | ["ingest_result"] |
| skills_invoked | ["SKILL-BOOTSTRAP-MEMORY-INGEST-CLOUD-001"] |
Bootstrap Memory Ingest — Cloud
Purpose / When to Activate
Activate:
- As Stage 5 of the
/gaai:bootstrap pipeline, Cloud path only
- After
bootstrap-llm-synthesis (Stage 3) has produced validated memory entries
- When the workspace bootstrap_status is
in_progress (set by the bootstrap orchestrator)
- Do NOT activate if the workspace bootstrap_status is anything other than
in_progress — the server gate will refuse all writes
Pre-conditions
Before activating, verify:
- The GAAI Cloud MCP session is active
synthesis_result.entries is non-empty
- workspace
bootstrap_status = in_progress (checked implicitly by the server gate — no pre-flight check needed)
Process Steps
Loop: for each entry in synthesis_result.entries
-
Call gaai_memory MCP tool:
{
"action": "store",
"scope": "ws",
"category": "<entry.category>",
"topic": "<entry.topic>",
"content": "<entry.content>",
"tags": ["<entry.tags...>"],
"source": "bootstrap"
}
-
On success (result.action = "created" or "updated"):
- Increment
success_count
- Log entry:
[OK] <category>/<topic> → <action>
-
On error (response has isError: true or contains code field):
- Increment
fail_count
- Capture error:
{ category, topic, code, error }
- Log entry:
[FAIL] <category>/<topic> → <code>: <error>
- Continue to next entry — per-entry errors never abort the loop
After loop: produce ingest_result
{
"success_count": <N>,
"fail_count": <M>,
"errors": [
{ "category": "...", "topic": "...", "code": "...", "error": "..." }
]
}
Report summary to user:
"Bootstrap ingest complete: {success_count} written, {fail_count} failed"
- If
fail_count > 0: list the failed entries with their error codes
Server-Side Gate Behavior (AC6)
The source: 'bootstrap' parameter activates the server-side bootstrap gate on each write:
| Condition | Server response |
|---|
bootstrap_status = 'in_progress' AND category not blocked | Write proceeds (HTTP 200 / MCP success) |
bootstrap_status != 'in_progress' | code: BOOTSTRAP_NOT_ACTIVE |
category = 'decisions' (any topic) | code: BOOTSTRAP_CATEGORY_BLOCKED |
category = 'rules' AND topic starts with active. | code: BOOTSTRAP_CATEGORY_BLOCKED |
Blocked categories are not writeable by bootstrap. Entries with code: BOOTSTRAP_CATEGORY_BLOCKED are per-entry failures — increment fail_count and continue.
Audit Events (AC3)
For each successful write with source: 'bootstrap', the server emits a memory.bootstrap.ingest audit event:
action: "memory.bootstrap.ingest"
resource: "memory"
target: "<category>/<topic>"
verdict: "OK"
details.entry_action: "created" or "updated"
This event is emitted server-side — no client-side action required.
Dedup Behavior (AC2)
Re-running bootstrap (re-calling this skill with the same category+topic) does NOT produce duplicates.
The HMAC-based dedup in StructuredMemory.store() treats a second write as an updated action on the existing row. The ingest_result.success_count will reflect this as a successful write.
Non-Goals (Out of Scope)
- LLM inference: This skill does NOT call the LLM. Call
bootstrap-llm-synthesis first.
- Consent gate: This skill does NOT show the consent overlay. That is a later pipeline stage.
- Local OSS path: This skill is Cloud-native only. For local-only bootstrap, entries are written to
.gaai/project/contexts/memory/ filesystem directly by the bootstrap orchestrator.
- Error recovery: Per-entry errors are logged and skipped. No retry logic. If
fail_count > 0, the operator should review the errors and re-run if needed.
- Status transition: This skill does NOT change
bootstrap_status. The orchestrator transitions in_progress → done after the consent stage.