[Feature]: Supported live-document plugin contract for Excel and PowerPoint

Feature Description

Hermes is a strong central cockpit for memory, sources, skills, routing, and quality control. However, Excel and PowerPoint power users must leave that cockpit when they need reliable native document editing.

File-based generation with Python libraries is useful, but it does not expose the live Office application state. It cannot reliably provide the same formula recalculation, chart and layout fidelity, template behavior, selection awareness, preview, or undo experience as an add-in operating inside the open workbook or presentation.

This creates a split workflow:

1. Users prepare context and analysis in Hermes.
2. They move to a native Office assistant to edit the live file.
3. The Office work and its decisions do not return automatically to the Hermes session, memory, or audit trail.

An independent Excel plugin already demonstrates the right architecture: lEWFkRAD/hermes-excel-sidecar, derived from closed PR #44356. It connects an Office.js task pane to the Hermes api_server through a local bridge and supports structured workbook actions, review-before-apply, verification, and undo. However, this path remains difficult to discover, depends on a compatible runtime contract, and has no equivalent PowerPoint workflow.

The request is not to add Microsoft Office vendor code to Hermes core. It is to make live-document integrations a supported, documented plugin pattern and to close the PowerPoint and round-trip context gaps.

Motivation

For Excel and PowerPoint work, output quality depends on access to the live application, not only on model quality.

Without a supported live-document bridge:

• Hermes cannot inspect the user's current selection or active document state.
• File-based edits can lose formatting, cached formula values, charts, masters, or layout fidelity.
• Users cannot review a proposed change set before it touches the document.
• There is no consistent Apply/Discard/Undo contract across Office integrations.
• Work completed inside an Office add-in is not written back to the originating Hermes session.
• Users must choose between Hermes centralization and the better native editing experience offered by Office-specific assistants.

This is distinct from:

• #4438, which covers file-based spreadsheet tools and skills;
• #81159, which covers read-only Office previews in Hermes Desktop;
• #44356, which implemented an Excel sidecar but was closed in favor of a standalone plugin.

Proposed Solution

Define and document an Office live-document plugin contract that standalone plugins can implement without patches to Hermes core.

1. Stable runtime contract

Document and test the supported interface between an Office add-in bridge and Hermes:

• profile and session selection;
• authenticated local api_server access;
• typed document-action responses;
• tool containment for document-only sessions;
• cancellation and request deadlines;
• attachment handoff;
• compatibility/version negotiation;
• clear failure behavior when the runtime is incompatible.

2. Common review and audit semantics

Provide a recommended action envelope that supports:

• Preview / Apply / Discard;
• bounded reads from the live document;
• post-write verification;
• Undo based on document fingerprints;
• a structured summary of applied changes;
• optional write-back of that summary to the originating Hermes session.

This would let Hermes remain the durable cockpit while Office remains the native editing surface.

3. Reference plugin documentation

Add a documented reference path for standalone Office.js plugins. If it meets the project's security and maintenance requirements, list hermes-excel-sidecar as a reference implementation rather than duplicating it in core.

The documentation should include:

• recommended plugin packaging;
• profile ownership and multi-profile behavior;
• local bridge authentication;
• sideloading requirements;
• security boundaries;
• runtime compatibility checks;
• deployment and rollback guidance.

4. PowerPoint parity

Define a PowerPoint action schema and reference workflow for:

• reading the current slide, selected shapes, notes, and presentation theme;
• creating and updating native text, tables, charts, and shapes;
• preserving slide masters and layouts;
• reviewing changes before apply;
• detecting text overflow and off-slide objects;
• returning the applied-change summary to Hermes.

This can ship as a separate standalone plugin. It does not need to be part of core.

5. Cross-application handoff

Support a documented way for an Excel plugin to pass selected ranges, chart data, assumptions, and source references to a PowerPoint plugin through the same Hermes session. The handoff should preserve source provenance and avoid copying opaque binary state into the prompt.

Acceptance Criteria

• A public, versioned plugin contract exists for live-document integrations.
• A standalone Excel plugin can detect compatibility without requiring a companion patch to Hermes core.
• A plugin can bind to a specific Hermes profile and session without exposing unrelated profile state.
• Applied Office changes can return a structured summary to the originating Hermes session.
• The contract supports Preview / Apply / Discard, verification, cancellation, and Undo semantics.
• PowerPoint has a documented typed-action schema or reference plugin path.
• The documentation clearly separates file-based skills, Desktop preview, and live Office editing.

Alternatives Considered

File-based spreadsheet and presentation skills

These remain useful for batch generation and unattended automation, but they do not provide the live application context or native editing fidelity required for high-stakes Office work.

Office previews inside Hermes Desktop

Preview support improves review, but it does not let Hermes safely manipulate the live workbook or presentation.

Copy and paste between Hermes and an Office assistant

This works today, but it breaks session continuity, durable memory, provenance, and auditability. It also forces users to maintain two separate contexts manually.

Merge a Microsoft-specific integration into Hermes core

This would conflict with the project's plugin-first policy for third-party product integrations. A stable runtime contract plus standalone plugins is the lower-coupling approach.

Additional Context

The existing Excel sidecar and its earlier upstream PR show that the concept is feasible. The missing product layer is a supported integration contract, discoverability, PowerPoint parity, and a reliable round trip back to Hermes.