Lightweight containerized prosody tooling + moved auth scripts + xmpp reconnect/auth stabilization
This commit is contained in:
36
artifacts/plans/01-canonical-conversation-events.md
Normal file
36
artifacts/plans/01-canonical-conversation-events.md
Normal file
@@ -0,0 +1,36 @@
|
||||
# Feature Plan: Canonical Conversation Events (Append-Only Timeline)
|
||||
|
||||
## Goal
|
||||
Introduce a canonical append-only event log for conversations so adapters remain stateless and replay/debugging become deterministic.
|
||||
|
||||
## Why This Fits GIA
|
||||
- GIA already has `Person`, `PersonIdentifier`, `ChatSession`, `Message` and multi-transport routing.
|
||||
- This adds a durable event backbone without replacing current UI/features.
|
||||
|
||||
## Scope
|
||||
- Add `ConversationEvent` model (append-only).
|
||||
- Event types: `message_created`, `message_edited`, `message_deleted`, `reaction_added`, `reaction_removed`, `read_receipt`, `media_attached`, `participant_added`, `participant_removed`.
|
||||
- Persist source metadata: transport, upstream IDs, timestamps, actor, payload.
|
||||
- Write events from transport ingress and internal compose actions.
|
||||
- Build replay utility for one chat/session.
|
||||
|
||||
## Implementation
|
||||
1. Add model + migration + indexes (`session`, `event_type`, `created_at`, `origin_transport+origin_message_id`).
|
||||
2. Add write helper in a new module (`core/events/ledger.py`).
|
||||
3. Update signal/whatsapp/xmpp ingress handlers to emit canonical events.
|
||||
4. Update compose send/reaction/edit/delete paths to emit canonical events.
|
||||
5. Add admin/diagnostic read view for event stream by session.
|
||||
6. Add replay command to regenerate derived projections.
|
||||
|
||||
## Acceptance Criteria
|
||||
- Every new message/reaction/edit/delete creates exactly one canonical event.
|
||||
- Event ordering is deterministic per session.
|
||||
- Replay reproduces message projection for a selected session.
|
||||
- No adapter requires business logic to infer missing event state.
|
||||
|
||||
## Risks
|
||||
- Double-write races during transition.
|
||||
- Backfill complexity for old messages.
|
||||
|
||||
## Out of Scope
|
||||
- Full migration of all legacy records in one release.
|
||||
28
artifacts/plans/02-transport-capability-matrix.md
Normal file
28
artifacts/plans/02-transport-capability-matrix.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# Feature Plan: Transport Capability Matrix
|
||||
|
||||
## Goal
|
||||
Define transport feature capabilities centrally so router/policy/UI can make deterministic decisions.
|
||||
|
||||
## Why This Fits GIA
|
||||
- GIA currently spans Signal/WhatsApp/Instagram/XMPP with uneven feature support.
|
||||
- Prevents silent failures (for example reaction exists internally but cannot be sent outward).
|
||||
|
||||
## Scope
|
||||
- Add capability registry per transport.
|
||||
- Features: reactions, edits, deletes, threaded replies, typing, media classes, read receipts, participant events.
|
||||
- Runtime helper APIs used by router and compose UI.
|
||||
|
||||
## Implementation
|
||||
1. Add `core/transports/capabilities.py` with static matrix + version field.
|
||||
2. Expose query helpers: `supports(service, feature)` and `unsupported_reason(...)`.
|
||||
3. Integrate checks into `core/clients/transport.py` send/reaction/edit paths.
|
||||
4. Compose UI: disable unsupported actions with clear hints.
|
||||
5. Add tests per service for expected behavior.
|
||||
|
||||
## Acceptance Criteria
|
||||
- Unsupported action never calls transport adapter.
|
||||
- User receives explicit, actionable error.
|
||||
- Service capabilities are test-covered and easy to update.
|
||||
|
||||
## Out of Scope
|
||||
- Dynamic remote capability negotiation.
|
||||
28
artifacts/plans/03-media-asset-normalization.md
Normal file
28
artifacts/plans/03-media-asset-normalization.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# Feature Plan: Media Asset Normalization
|
||||
|
||||
## Goal
|
||||
Normalize media into reusable assets so messages reference media IDs rather than duplicate transport blobs.
|
||||
|
||||
## Why This Fits GIA
|
||||
- GIA already has shared media prep and cross-transport relay.
|
||||
- Normalized assets reduce duplicate downloads/uploads and improve traceability.
|
||||
|
||||
## Scope
|
||||
- New `MediaAsset` entity with checksum + metadata.
|
||||
- New link table between `Message` and `MediaAsset`.
|
||||
- De-dup by `sha256` and file size.
|
||||
|
||||
## Implementation
|
||||
1. Add models/migrations: `MediaAsset`, `MessageMediaRef`.
|
||||
2. Update inbound media ingestion to upsert `MediaAsset`.
|
||||
3. Update outbound transport prep to consume `MediaAsset` references.
|
||||
4. Add background backfill for existing attachments.
|
||||
5. Add retention/GC strategy for orphaned assets.
|
||||
|
||||
## Acceptance Criteria
|
||||
- Same file across transports resolves to one `MediaAsset`.
|
||||
- Message records keep only pointers and display metadata.
|
||||
- Relay path can reuse existing asset without re-download.
|
||||
|
||||
## Out of Scope
|
||||
- External CDN migration in this phase.
|
||||
27
artifacts/plans/04-identity-resolution-and-merge.md
Normal file
27
artifacts/plans/04-identity-resolution-and-merge.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# Feature Plan: Identity Resolution and Merge
|
||||
|
||||
## Goal
|
||||
Improve person graph quality by suggesting and applying safe merges across transport identifiers.
|
||||
|
||||
## Why This Fits GIA
|
||||
- Core value of universal inbox depends on clean `Person` identity graph.
|
||||
|
||||
## Scope
|
||||
- Heuristic scoring for candidate merges.
|
||||
- Manual review queue with approve/reject.
|
||||
- Merge operation with audit trail and undo window.
|
||||
|
||||
## Implementation
|
||||
1. Add scoring service using signals: normalized phone, username similarity, name overlap, shared chat co-occurrence.
|
||||
2. Add `IdentityMergeSuggestion` model with score + reasons.
|
||||
3. Add UI panel to review/approve merges.
|
||||
4. Implement safe merge transaction (`PersonIdentifier` reassignment, metadata merge rules).
|
||||
5. Emit audit events and rollback snapshots.
|
||||
|
||||
## Acceptance Criteria
|
||||
- Suggestions generated deterministically and explain reasons.
|
||||
- Merge is idempotent and reversible within configured window.
|
||||
- No identifier is lost or orphaned.
|
||||
|
||||
## Out of Scope
|
||||
- Fully automatic merge without human approval.
|
||||
27
artifacts/plans/05-adapter-resilience-supervisor.md
Normal file
27
artifacts/plans/05-adapter-resilience-supervisor.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# Feature Plan: Adapter Resilience Supervisor
|
||||
|
||||
## Goal
|
||||
Make adapters self-healing and observable under disconnects, API drift, and transient faults.
|
||||
|
||||
## Why This Fits GIA
|
||||
- Bridge reliability is a product requirement for multi-network ops.
|
||||
|
||||
## Scope
|
||||
- Health probes per adapter.
|
||||
- Reconnect/backoff supervisor.
|
||||
- Circuit-breaker for repeated failure classes.
|
||||
|
||||
## Implementation
|
||||
1. Add adapter health state model (healthy/degraded/down).
|
||||
2. Add watchdog jobs for Signal/WhatsApp/Instagram/XMPP.
|
||||
3. Implement exponential backoff + jitter reconnect policies.
|
||||
4. Emit structured adapter health events + alerts.
|
||||
5. Add status surface in settings/services pages.
|
||||
|
||||
## Acceptance Criteria
|
||||
- Adapter restarts automatically on transient failures.
|
||||
- Repeated failures degrade state and stop spam retries.
|
||||
- Operators can view current health + last error + retry schedule.
|
||||
|
||||
## Out of Scope
|
||||
- Full protocol hot-reload without process restart.
|
||||
27
artifacts/plans/06-end-to-end-observability.md
Normal file
27
artifacts/plans/06-end-to-end-observability.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# Feature Plan: End-to-End Observability and Traceability
|
||||
|
||||
## Goal
|
||||
Provide trace-level visibility from ingress transport event to UI delivery/ack.
|
||||
|
||||
## Why This Fits GIA
|
||||
- Multi-hop messaging systems require correlation IDs to debug reliably.
|
||||
|
||||
## Scope
|
||||
- Global trace IDs for message lifecycle.
|
||||
- Structured logs and timeline diagnostics view.
|
||||
- Basic metrics and SLA dashboards.
|
||||
|
||||
## Implementation
|
||||
1. Inject `trace_id` at ingress/send initiation.
|
||||
2. Propagate through router, persistence, websocket, command/task flows.
|
||||
3. Standardize structured log schema across services.
|
||||
4. Add timeline diagnostics page by trace ID and session.
|
||||
5. Add core metrics: ingress latency, send latency, drop rate, retry counts.
|
||||
|
||||
## Acceptance Criteria
|
||||
- One trace ID can reconstruct full message path.
|
||||
- At least 95% of critical paths emit structured trace logs.
|
||||
- Operators can isolate bottleneck stage in under 2 minutes.
|
||||
|
||||
## Out of Scope
|
||||
- Full distributed tracing vendor integration.
|
||||
25
artifacts/plans/07-unified-conversation-graph-ui.md
Normal file
25
artifacts/plans/07-unified-conversation-graph-ui.md
Normal file
@@ -0,0 +1,25 @@
|
||||
# Feature Plan: Unified Conversation Graph UI
|
||||
|
||||
## Goal
|
||||
Expose one-person-many-identifiers graph in UI so users work per person, not per transport fragment.
|
||||
|
||||
## Why This Fits GIA
|
||||
- GIA already models `Person` + `PersonIdentifier`; this surfaces it clearly.
|
||||
|
||||
## Scope
|
||||
- Person profile panel with linked identifiers and active sessions.
|
||||
- Cross-transport thread pivoting from one card.
|
||||
- Merge/split controls linked to identity suggestions.
|
||||
|
||||
## Implementation
|
||||
1. Add graph view endpoint and serializer for person graph.
|
||||
2. Update compose sidebar/person pages with linked transport pills.
|
||||
3. Add quick actions: open thread, relink identifier, propose merge.
|
||||
4. Integrate with identity merge queue from feature 04.
|
||||
|
||||
## Acceptance Criteria
|
||||
- User can see and navigate all transport identities for a person from one place.
|
||||
- Switching transport context preserves person-centric history access.
|
||||
|
||||
## Out of Scope
|
||||
- Force-merged unified thread rendering across all transports.
|
||||
27
artifacts/plans/08-conversation-intelligence-suite.md
Normal file
27
artifacts/plans/08-conversation-intelligence-suite.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# Feature Plan: Conversation Intelligence Suite
|
||||
|
||||
## Goal
|
||||
Add actionable conversation analytics and AI-assisted summaries with transparent outputs.
|
||||
|
||||
## Why This Fits GIA
|
||||
- AI workspace already exists; this extends it with communication-specific signals.
|
||||
|
||||
## Scope
|
||||
- Metrics: response latency, engagement symmetry, activity trend.
|
||||
- AI summary for recent window with action item extraction.
|
||||
- Draft mediation suggestions with raw/original always visible.
|
||||
|
||||
## Implementation
|
||||
1. Add analytics service computing per-thread/person metrics.
|
||||
2. Add summary generation endpoint with cached recent windows.
|
||||
3. Add action-item extraction that can feed tasks pipeline.
|
||||
4. Compose UI card: metrics + summary + suggested next reply.
|
||||
5. Add "show raw" indicator whenever mediation is displayed.
|
||||
|
||||
## Acceptance Criteria
|
||||
- Metrics refresh reliably on new events.
|
||||
- Summaries are attributable to explicit message windows.
|
||||
- Mediation never hides original user text.
|
||||
|
||||
## Out of Scope
|
||||
- Fully autonomous outbound sending.
|
||||
27
artifacts/plans/09-task-automation-from-chat.md
Normal file
27
artifacts/plans/09-task-automation-from-chat.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# Feature Plan: Task Automation from Chat
|
||||
|
||||
## Goal
|
||||
Strengthen chat-to-task conversion with due dates, assignees, and conversation links.
|
||||
|
||||
## Why This Fits GIA
|
||||
- Task extraction and command flows already exist and are active.
|
||||
|
||||
## Scope
|
||||
- Parse due date/owner hints from task-like messages.
|
||||
- Persist task-to-message and task-to-session links explicitly.
|
||||
- Improve task status announcements and query commands.
|
||||
|
||||
## Implementation
|
||||
1. Extend task parser with lightweight date/owner extraction rules.
|
||||
2. Add fields (or payload keys) for due date and assignee identifier.
|
||||
3. Add `.task list`, `.task show #id`, `.task complete #id` command aliases.
|
||||
4. Add per-chat task digest message schedule option.
|
||||
5. Add robust undo/audit entry for automated task creation.
|
||||
|
||||
## Acceptance Criteria
|
||||
- Task extraction preserves source message context.
|
||||
- Due date extraction is deterministic and tested for common phrases.
|
||||
- Command UX remains lenient and case-insensitive.
|
||||
|
||||
## Out of Scope
|
||||
- Full project management board UX.
|
||||
27
artifacts/plans/10-policy-engine-middleware.md
Normal file
27
artifacts/plans/10-policy-engine-middleware.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# Feature Plan: Policy Engine Middleware
|
||||
|
||||
## Goal
|
||||
Implement deterministic middleware policies for inbound/outbound message transforms and automations.
|
||||
|
||||
## Why This Fits GIA
|
||||
- Existing command/task/approval flows provide natural control points.
|
||||
|
||||
## Scope
|
||||
- Per-chat and per-person policy rules.
|
||||
- Rule actions: notify, suggest rewrite, create task, rate-limit send, require approval.
|
||||
- Dry-run/audit mode for every policy decision.
|
||||
|
||||
## Implementation
|
||||
1. Add policy schema and evaluator (`if conditions -> actions`).
|
||||
2. Hook evaluator into compose send and inbound task intelligence paths.
|
||||
3. Add policy decision logs with trace IDs.
|
||||
4. Add UI for policy creation/testing with preview mode.
|
||||
5. Add safe defaults: all transform rules start as suggest-only.
|
||||
|
||||
## Acceptance Criteria
|
||||
- Policy decisions are deterministic and replayable.
|
||||
- Any transform is visibly annotated in UI.
|
||||
- Users can disable policy per chat instantly.
|
||||
|
||||
## Out of Scope
|
||||
- Natural-language-to-policy compiler in first release.
|
||||
28
artifacts/plans/11-personal-ai-memory.md
Normal file
28
artifacts/plans/11-personal-ai-memory.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# Feature Plan: Personal AI Memory (Per Person)
|
||||
|
||||
## Goal
|
||||
Store and manage long-lived person-specific memory for better continuity and assistant quality.
|
||||
|
||||
## Why This Fits GIA
|
||||
- Person-centric data model already exists.
|
||||
- Current approvals pattern can gate memory writes.
|
||||
|
||||
## Scope
|
||||
- Memory entries: preferences, commitments, facts, communication style.
|
||||
- Confidence/expiry fields and provenance links.
|
||||
- Approval-required writes with edit/delete controls.
|
||||
|
||||
## Implementation
|
||||
1. Add memory model linked to `Person` with source references.
|
||||
2. Add extraction pipeline (suggested memory from messages).
|
||||
3. Add approval queue for memory create/update/delete.
|
||||
4. Add retrieval service for compose/AI workspace prompts.
|
||||
5. Add memory hygiene jobs: stale decay, contradiction detection.
|
||||
|
||||
## Acceptance Criteria
|
||||
- Every memory has provenance and last-verified timestamp.
|
||||
- Unapproved memory never influences generated output.
|
||||
- Users can inspect, edit, and purge memory entries.
|
||||
|
||||
## Out of Scope
|
||||
- Cross-user shared memory graph.
|
||||
60
artifacts/plans/12-mcp-server-for-tasks-and-knowledge.md
Normal file
60
artifacts/plans/12-mcp-server-for-tasks-and-knowledge.md
Normal file
@@ -0,0 +1,60 @@
|
||||
# Feature Plan: MCP Server for Tasks + Wiki/Knowledgebase
|
||||
|
||||
## Goal
|
||||
Create an MCP server that allows agents to:
|
||||
- read/write task context,
|
||||
- create/update knowledgebase/wiki artifacts during task execution,
|
||||
- retrieve coding guidelines/project layout for continuity between runs.
|
||||
|
||||
## Why This Fits GIA
|
||||
- Tasks, approvals, and command-driven automation already exist.
|
||||
- This provides durable agent memory and operator visibility of "what changed, why, and how to use it".
|
||||
|
||||
## Scope
|
||||
- MCP server with authenticated tools for:
|
||||
- `tasks.list`, `tasks.get`, `tasks.search`, `tasks.events`
|
||||
- `tasks.create_note`, `tasks.link_artifact`
|
||||
- `wiki.create_article`, `wiki.update_article`, `wiki.list`, `wiki.get`
|
||||
- `project.get_layout`, `project.get_guidelines`, `project.get_runbook`
|
||||
- Permission model tied to user and chat/project scope.
|
||||
- Audit log for all MCP tool calls.
|
||||
|
||||
## Proposed Data Additions
|
||||
- `KnowledgeArticle` (title, slug, markdown, tags, status, owner, related_task).
|
||||
- `KnowledgeRevision` (article, revision, author/tool, diff, created_at).
|
||||
- Optional `TaskArtifactLink` (task, kind, uri/path, summary).
|
||||
|
||||
## Implementation
|
||||
1. Build MCP server process (Python) with JSON-RPC transport and token auth.
|
||||
2. Implement task read tools against existing task models/views.
|
||||
3. Implement wiki CRUD tools with revision history.
|
||||
4. Implement project context tools that read:
|
||||
- `AGENTS.md`,
|
||||
- coding standards docs,
|
||||
- key architecture docs.
|
||||
5. Add agent-run convention:
|
||||
- on task start: fetch task + related wiki + guidelines,
|
||||
- during run: append execution notes,
|
||||
- on completion: publish "what was done / how to use" article and link to task.
|
||||
6. Add web UI page for knowledge articles and task-linked docs.
|
||||
7. Add approvals for destructive knowledge actions (delete/overwrite).
|
||||
|
||||
## Acceptance Criteria
|
||||
- Agent can fetch full task context in one MCP call sequence.
|
||||
- Agent can publish/update wiki pages tied to tasks.
|
||||
- Operators can open a task and see linked implementation notes + usage docs.
|
||||
- MCP actions are fully auditable and scoped by user permissions.
|
||||
|
||||
## Security and Guardrails
|
||||
- Tool-level RBAC and per-user scoping.
|
||||
- Redact secrets from returned context.
|
||||
- Rate limits and request signing for external agent clients.
|
||||
|
||||
## Rollout
|
||||
1. Read-only task tools.
|
||||
2. Wiki write tools with revisioning.
|
||||
3. Task artifact linking + UI surfaces.
|
||||
4. Agent workflow templates and docs.
|
||||
|
||||
## Out of Scope
|
||||
- Autonomous code execution from MCP itself.
|
||||
16
artifacts/plans/13-edit-delete.md
Normal file
16
artifacts/plans/13-edit-delete.md
Normal file
@@ -0,0 +1,16 @@
|
||||
Perfect, so it all works?
|
||||
|
||||
the message saying "the recipient does the same" has been reacted to with a heart but it is not shown in web compose
|
||||
|
||||
I also sent an erronrous message, a literal reply to a message that i said i would react to with a heart. the message contained a heart emoji, so it is a reply with a heart and not a reaction
|
||||
|
||||
after some confusion I deleted this message
|
||||
|
||||
can deleted messages be noted and collected for storage in a deleted message tab in compose that lists what each recipient deleted and when
|
||||
|
||||
ensure message edit history is shown, and preserved if the message is deleted, seamlessly reusing the navigation code to preserve a unified interface
|
||||
|
||||
work on implementing edit message tracking and delete message indications
|
||||
|
||||
consider how to implement
|
||||
|
||||
Reference in New Issue
Block a user