mt5cli 1.1.1__tar.gz → 1.1.2__tar.gz

{mt5cli-1.1.1 → mt5cli-1.1.2}/.agents/skills/pr-feedback-triage/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: pr-feedback-triage
 description: Triage pull request review comments into fixes, replies, clarification requests, or open follow-ups while respecting safe execution modes.
+allowed-tools: Bash(git:*), Bash(gh:*), mcp__github__*, Read, Grep, Glob, Edit, MultiEdit, Write
 ---
 
 # PR Feedback Triage
@@ -43,9 +44,10 @@ When a mode disables an action, skip that destructive or externally visible acti
 
 Gather the complete feedback set before editing:
 
-- Fetch unresolved review threads, requested-change reviews, PR-level summary comments, and copied comments.
-- Use platform-native APIs/CLI when available. Paginate results; do not inspect only the first page of threads or comments.
-- For bot reviewers that post both summary comments and inline comments, collect both. Summary comments often contain severity, rationale, and fix instructions; inline comments contain the exact file and line context.
+- Fetch unresolved review threads, requested-change reviews, inline comments, copied comments, and PR-level summary comments.
+- Use whichever authenticated GitHub-capable interface is available and reliable. This skill explicitly permits both `gh` and GitHub MCP tools; paginate results and do not inspect only the first page of threads or comments.
+- For bot reviewers that post both summary comments and inline comments, prefer inline comments for actionable triage. Incorporate summary findings only when they contain distinct severity, rationale, or fix instructions not already captured from inline comments.
+- Summary comments may be excluded from triage when they do not add distinct actionable context.
 - Preserve every thread/comment identifier needed to reply or resolve later.
 - Compare each comment with the current diff and file contents because review lines can become outdated.
 
@@ -56,7 +58,7 @@ Build one triage record per distinct finding:
 - Prefer exact review-thread identity when available.
 - For duplicate bot findings appearing in both summary and inline comments, merge by exact issue title first, then by file path plus line range as a fallback.
 - Prefer inline comments for location and current code context.
-- Prefer summary comments for severity, category, rationale, and detailed agent prompts.
+- Use summary comments only for distinct severity, category, rationale, or detailed agent prompts that are not already available from inline comments.
 - Preserve the reviewer’s exact issue title and original wording where practical. Do not rename findings in a way that would make replies hard to map back to comments.
 - Preserve the reviewer’s original ordering unless the user asks for priority reordering. Many review bots already order findings by severity.
 
@@ -70,13 +72,20 @@ Keep a thread open only when it still needs reviewer, maintainer, or product inp
 
 When resolving a thread, add a concise reply first only if it provides useful context, such as what changed, why no code change was needed, why a finding was intentionally deferred, or why the original comment is now outdated. Do not add noisy replies for self-evident fixes unless project norms require them.
 
+## Platform Comment Style
+
+- Keep every posted reply or comment brief: one sentence by default, two short sentences only when necessary.
+- Do not post PR-level summary or status comments by default. Omit them when they only restate completed fixes, resolved threads, or verification already visible in commits/checks.
+- Avoid templates, long bullet lists, exhaustive status logs, and duplicated explanations in platform comments.
+- For simple fixes, already-addressed findings, or outdated findings, prefer `resolve_only` over adding a reply.
+
 ## Platform Action Contract
 
-Do not treat triage as complete until every collected source ID reaches an explicit terminal state:
+Do not treat triage as complete until every incorporated source ID reaches an explicit terminal state:
 
 - `resolved`: a platform resolve action succeeded, or a re-check shows the thread is already resolved.
 - `replied_left_open`: a reply or question was posted and the thread is intentionally left unresolved.
-- `not_resolvable`: the source is a PR-level summary comment or copied comment that has no platform-level resolve action; reply or post a PR summary when useful.
+- `not_resolvable`: the source is a PR-level summary comment or copied comment that has no platform-level resolve action; post a brief reply only when useful.
 - `skipped_by_mode`: `dry_run`, `no_push`, or `no_reply` prevented the external action.
 - `failed_action`: a reply or resolve action was attempted and failed; include the attempted action and failure in the final summary.
 
@@ -85,13 +94,13 @@ In normal mode, build and execute a platform action queue after fixes are verifi
 - `reply_then_resolve`: use for handled threads where the reviewer needs context before resolution.
 - `resolve_only`: use for self-evident fixes and already-addressed or outdated threads where an extra reply would add noise.
 - `reply_leave_open`: use only for clarification requests, blocked work, or intentionally open follow-ups.
-- `reply_only`: use for PR-level comments or summaries that cannot be resolved as review threads.
+- `reply_only`: use for PR-level comments or summaries that cannot be resolved, only when a short reply adds value.
 
 For duplicate findings, execute the terminal action for every source thread ID, not only the primary triage record. If one finding is represented by three unresolved inline threads, all three must be resolved or explicitly left open.
 
 ## GitHub Action Guidance
 
-Prefer platform-native APIs or `gh` commands that expose review-thread resolution state. For GitHub inline review threads, use the thread node ID and the GraphQL `resolveReviewThread` mutation rather than assuming that a reply resolves the conversation.
+Use whichever authenticated GitHub-capable interface is available and reliable, preferably `gh` or GitHub MCP. Prefer interfaces that expose review-thread resolution state. For GitHub inline review threads, use the thread node ID and the GraphQL `resolveReviewThread` mutation, or an equivalent GitHub MCP resolve-thread tool, rather than assuming that a reply resolves the conversation.
 
 A reliable pattern is:
 
@@ -150,9 +159,9 @@ flowchart TD
 ## Compact Workflow
 
 1. **Collect all relevant feedback**
-   - Identify the PR and gather unresolved review threads, requested-change reviews, PR-level summaries, inline comments, and copied comments.
+   - Identify the PR and gather unresolved review threads, requested-change reviews, inline comments, copied comments, and PR-level summaries.
    - Paginate all platform calls and keep comment/thread IDs for later replies and resolution.
-   - For bot reviews, collect both summary and inline comments, then merge duplicates rather than fixing the same finding twice.
+   - For bot reviews, prioritize inline comments and incorporate summary findings only when they add distinct actionable context.
 
 2. **Classify each triage record**
    - **Fix**: Valid requested change; make the smallest focused edit when not in `dry_run`.
@@ -168,7 +177,7 @@ flowchart TD
    - In `dry_run`, stop at triage, proposed fixes, suggested replies, and verification plan.
    - In `no_push`, local edits are allowed, but do not push or resolve threads whose fix is only local. Reply or resolve non-code, already-addressed, or outdated threads only when the action does not depend on unpushed work and `no_reply` is not set.
    - In `no_reply`, do not post replies or resolve threads; report suggested replies/actions instead.
-   - In normal mode, commit and push changed code when appropriate, then execute the platform action queue for every collected source ID.
+   - In normal mode, commit and push changed code when appropriate, then execute the platform action queue for every incorporated source ID.
 
 4. **Verify before claiming completion**
    - For fixes, run appropriate checks or explain why they could not run.
@@ -178,15 +187,16 @@ flowchart TD
    - If a resolve or reply operation fails, retry once when safe; then report `failed_action` with the affected source ID and reason.
 
 5. **Finish**
-   - Normal mode: commit/push changes when appropriate, post useful replies or a summary, resolve all handled threads by default, and reconcile the final unresolved set.
+   - Normal mode: commit/push changes when appropriate, post only useful short replies/comments, omit PR-level summaries when they add no value, resolve all handled threads by default, and reconcile the final unresolved set.
    - Safe modes: report the local state and the exact replies/resolution actions a human could take.
 
 ## Reply Guidance
 
-- Keep inline replies short and tied to the original title or concern.
-- For fixed findings, mention the concrete change or commit if useful.
-- For already-addressed or outdated findings, cite the current code path or behavior that makes the finding no longer applicable.
+- Keep inline replies short: one sentence by default, two short sentences only when needed.
+- For fixed findings, mention the concrete change or commit only if it helps the reviewer.
+- For already-addressed or outdated findings, cite the current code path or behavior only as briefly as needed.
 - For deferred or won't-fix findings, provide the reason and any follow-up issue or owner if known.
+- Avoid posting PR-level summary comments unless they communicate a decision, blocker, or requested reviewer action.
 - If a reply or resolve operation fails, continue with the remaining threads and report the failure in the final summary.
 
 ## Final Summary Checklist

mt5cli-1.1.2/.github/workflows/opencode.yml

@@ -0,0 +1,72 @@
+---
+name: Pull request review and mention bot using OpenCode
+on:
+  pull_request:
+    types:
+      - opened
+      - ready_for_review
+  issue_comment:
+    types:
+      - created
+  pull_request_review_comment:
+    types:
+      - created
+  pull_request_review:
+    types:
+      - submitted
+  issues:
+    types:
+      - opened
+      - assigned
+permissions:
+  contents: read
+jobs:
+  opencode-review:
+    if: >
+      github.event_name == 'pull_request'
+      && contains(fromJSON('["OWNER","MEMBER","COLLABORATOR"]'), github.event.pull_request.author_association)
+      && (! github.event.pull_request.draft)
+      && (! startsWith(github.head_ref, 'dependabot/'))
+      && (! startsWith(github.head_ref, 'renovate/'))
+    permissions:
+      contents: read
+      pull-requests: write
+      issues: write
+      id-token: write
+      actions: read
+    uses: dceoy/gh-actions-for-devops/.github/workflows/opencode-review.yml@main  # zizmor: ignore[unpinned-uses]
+    with:
+      model: opencode-go/kimi-k2.7-code
+    secrets:
+      OPENCODE_API_KEY: ${{ secrets.OPENCODE_API_KEY }}
+      GH_TOKEN: ${{ secrets.GH_TOKEN || secrets.GITHUB_TOKEN }}
+  opencode-bot:
+    if: >
+      (
+        (github.event_name == 'issue_comment' || github.event_name == 'pull_request_review_comment')
+        && contains(fromJSON('["OWNER","MEMBER","COLLABORATOR"]'), github.event.comment.author_association)
+        && (contains(github.event.comment.body, '/oc') || contains(github.event.comment.body, '/opencode'))
+      ) || (
+        github.event_name == 'pull_request_review'
+        && contains(fromJSON('["OWNER","MEMBER","COLLABORATOR"]'), github.event.review.author_association)
+        && (contains(github.event.review.body, '/oc') || contains(github.event.review.body, '/opencode'))
+      ) || (
+        github.event_name == 'issues'
+        && contains(fromJSON('["OWNER","MEMBER","COLLABORATOR"]'), github.event.issue.author_association)
+        && (
+          (contains(github.event.issue.body, '/oc') || contains(github.event.issue.title, '/oc'))
+          || (contains(github.event.issue.body, '/opencode') || contains(github.event.issue.title, '/opencode'))
+        )
+      )
+    permissions:
+      contents: read
+      pull-requests: write
+      issues: write
+      id-token: write
+      actions: read
+    uses: dceoy/gh-actions-for-devops/.github/workflows/opencode-bot.yml@main  # zizmor: ignore[unpinned-uses]
+    with:
+      model: opencode-go/glm-5.2
+    secrets:
+      OPENCODE_API_KEY: ${{ secrets.OPENCODE_API_KEY }}
+      GH_TOKEN: ${{ secrets.GH_TOKEN || secrets.GITHUB_TOKEN }}

{mt5cli-1.1.1 → mt5cli-1.1.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mt5cli
-Version: 1.1.1
+Version: 1.1.2
 Summary: Generic MT5 data and execution infrastructure for Python applications
 Project-URL: Repository, https://github.com/dceoy/mt5cli.git
 Author-email: dceoy <dceoy@users.noreply.github.com>
@@ -17,7 +17,9 @@ Classifier: Programming Language :: Python :: 3
 Classifier: Topic :: Office/Business :: Financial :: Investment
 Requires-Python: <3.14,>=3.11
 Requires-Dist: click>=8.1.0
-Requires-Dist: pdmt5>=1.0.0
+Requires-Dist: pandas>=2.2.2
+Requires-Dist: pdmt5>=1.0.4
+Requires-Dist: pydantic>=2.13.4
 Requires-Dist: typer>=0.15.0
 Provides-Extra: otel
 Requires-Dist: opentelemetry-api; extra == 'otel'
@@ -331,7 +333,11 @@ WHERE run_id = (SELECT MAX(run_id) FROM snapshot_runs WHERE status = 'ok');
 SELECT symbol, total_profit FROM grafana_trade_stats ORDER BY total_profit DESC;
 ```
 
-> **Note**: OpenTelemetry integration is intentionally not part of this release and is tracked separately.
+#### Grafana and telemetry API docs
+
+The shipped Grafana helpers are documented in [`docs/api/grafana.md`](docs/api/grafana.md), including `publish_grafana_copy()` for creating a WAL-safe published SQLite copy for Grafana.
+
+OpenTelemetry metrics are documented in [`docs/api/telemetry.md`](docs/api/telemetry.md), including `enable_otel_metrics()`, `configure_metrics()`, the `mt5cli[otel]` extra, and `OTEL_EXPORTER_OTLP_ENDPOINT`.
 
 ### Incremental history SDK
 

{mt5cli-1.1.1 → mt5cli-1.1.2}/README.md

@@ -302,7 +302,11 @@ WHERE run_id = (SELECT MAX(run_id) FROM snapshot_runs WHERE status = 'ok');
 SELECT symbol, total_profit FROM grafana_trade_stats ORDER BY total_profit DESC;
 ```
 
-> **Note**: OpenTelemetry integration is intentionally not part of this release and is tracked separately.
+#### Grafana and telemetry API docs
+
+The shipped Grafana helpers are documented in [`docs/api/grafana.md`](docs/api/grafana.md), including `publish_grafana_copy()` for creating a WAL-safe published SQLite copy for Grafana.
+
+OpenTelemetry metrics are documented in [`docs/api/telemetry.md`](docs/api/telemetry.md), including `enable_otel_metrics()`, `configure_metrics()`, the `mt5cli[otel]` extra, and `OTEL_EXPORTER_OTLP_ENDPOINT`.
 
 ### Incremental history SDK
 

mt5cli-1.1.2/docs/api/grafana.md

@@ -0,0 +1,25 @@
+# Grafana
+
+::: mt5cli.grafana
+
+## Grafana-ready SQLite workflow
+
+Use `ensure_grafana_schema(conn)` or the `grafana-schema` CLI command to create
+the snapshot tables, `grafana_*` views, and supporting indexes in one step.
+
+`publish_grafana_copy(source, target)` creates a consistent SQLite copy via the
+SQLite backup API, which is useful when the primary database is running in WAL
+mode and Grafana should read from a separate published file.
+
+## Main APIs
+
+- `ensure_grafana_schema()`: idempotently creates snapshot tables, Grafana
+  views, and indexes.
+- `create_grafana_views()`: rebuilds the shipped `grafana_*` views.
+- `create_grafana_indexes()`: creates read-oriented indexes for Grafana
+  queries.
+- `publish_grafana_copy()`: writes an atomic, WAL-safe published copy for a
+  Grafana datasource.
+
+For end-to-end snapshot collection examples, see the Grafana and observability
+section in the project `README.md`.

{mt5cli-1.1.1 → mt5cli-1.1.2}/docs/api/index.md

@@ -18,6 +18,8 @@ responsibilities.
 | [SDK](sdk.md)                             | Module-level fetch helpers, multi-account collectors, incremental history |
 | [Trading](trading.md)                     | Trading-capable sessions and operational helpers                          |
 | [History Collection (SQLite)](history.md) | SQLite schema, incremental writes, dedup, and rate views                  |
+| [Telemetry](telemetry.md)                 | OpenTelemetry metrics setup, meters, and emitted metric names             |
+| [Grafana](grafana.md)                     | Grafana-ready SQLite schema, views, snapshots, and published copies       |
 | [CLI](cli.md)                             | Typer commands that delegate to the Python API                            |
 | [Utils](utils.md)                         | Parsing helpers and Click parameter types                                 |
 

{mt5cli-1.1.1 → mt5cli-1.1.2}/docs/api/public-contract.md

@@ -20,8 +20,8 @@ Downstream code should import raw pdmt5 types and constants (such as
 from `pdmt5` when needed. mt5cli does not serve as a pass-through compatibility
 namespace for pdmt5. mt5cli's trading helpers type their client parameter against
 an internal protocol backed by `pdmt5.Mt5DataClient`; `Mt5TradingClient` is no
-longer required. `Mt5TradingError` is conditionally imported where still present
-in pdmt5, but mt5cli raises `Mt5OperationError` for all trading-related failures.
+longer required. `pdmt5.Mt5TradingError` was removed upstream in pdmt5 1.0.4;
+mt5cli raises `Mt5OperationError` for all trading-related failures.
 
 Note: the former `mt5cli` re-export `TICK_FLAG_MAP` corresponds to `COPY_TICKS_MAP`
 in pdmt5 — the name changed, it was not simply moved.

{mt5cli-1.1.1 → mt5cli-1.1.2}/docs/api/sdk.md

@@ -12,8 +12,8 @@ application.
 
 `collect_latest_rates_for_accounts_with_retries()` wraps
 `collect_latest_rates_for_accounts()` with bounded exponential backoff. Only
-`pdmt5.Mt5TradingError` and `pdmt5.Mt5RuntimeError` are retried; the final
-failure is re-raised once `retry_count` is exhausted.
+`pdmt5.Mt5RuntimeError` is retried; the final failure is re-raised once
+`retry_count` is exhausted.
 
 ```python
 from mt5cli import AccountSpec, collect_latest_rates_for_accounts_with_retries
@@ -32,8 +32,9 @@ rates = collect_latest_rates_for_accounts_with_retries(
 
 MetaTrader 5 `start_pos=0` includes the still-forming current bar as the last
 row. `fetch_latest_closed_rates()` handles one connected `MT5Client`; use
-`fetch_latest_closed_rates_for_trading_client()` from an active
-`Mt5TradingClient` session. Multi-account helpers fetch `count + 1` bars, drop
+`fetch_latest_closed_rates_for_trading_client()` from an active trading
+session created by `create_trading_client()`. Multi-account helpers fetch
+`count + 1` bars, drop
 that row with `drop_forming_rate_bar()`, and validate each series is non-empty. Returned frames are ordered
 oldest-to-newest and may contain fewer than `count` rows only when MT5 returns
 fewer closed bars.

mt5cli-1.1.2/docs/api/telemetry.md

@@ -0,0 +1,50 @@
+# Telemetry
+
+::: mt5cli.telemetry
+
+## Enabling OpenTelemetry metrics
+
+Install the optional exporter dependencies with:
+
+```bash
+uv add 'mt5cli[otel]'
+```
+
+Then enable the default OTLP HTTP pipeline:
+
+```python
+from mt5cli.telemetry import enable_otel_metrics
+
+enable_otel_metrics(service_name="mt5cli")
+```
+
+When `readers=None`, `enable_otel_metrics()` builds a
+`PeriodicExportingMetricReader` backed by the OTLP HTTP exporter and reads the
+endpoint from `OTEL_EXPORTER_OTLP_ENDPOINT`.
+
+If your application already owns an OpenTelemetry `Meter`, wire mt5cli into it
+directly with `configure_metrics(meter)`.
+
+## Emitted metric names
+
+`enable_otel_metrics()` / `configure_metrics()` register these instruments:
+
+- `mt5_history_update_duration_seconds`
+- `mt5_history_update_rows_total`
+- `mt5_history_update_failures_total`
+- `mt5_snapshot_update_duration_seconds`
+- `mt5_snapshot_update_failures_total`
+- `mt5_account_balance`
+- `mt5_account_equity`
+- `mt5_account_margin`
+- `mt5_account_margin_free`
+- `mt5_account_margin_level`
+- `mt5_position_profit`
+- `mt5_position_volume`
+- `mt5_terminal_connected`
+- `mt5_terminal_trade_allowed`
+- `mt5_terminal_trade_expert`
+- `mt5_last_successful_update_timestamp`
+
+The history metrics use a `dataset` attribute. Account and position gauges add
+labels such as `login`, `server`, and `symbol` where applicable.

{mt5cli-1.1.1 → mt5cli-1.1.2}/mkdocs.yml

@@ -65,6 +65,8 @@ nav:
       - SDK: api/sdk.md
       - Trading: api/trading.md
       - History Collection (SQLite): api/history.md
+      - Telemetry: api/telemetry.md
+      - Grafana: api/grafana.md
       - Utils: api/utils.md
 
 markdown_extensions:

{mt5cli-1.1.1 → mt5cli-1.1.2}/mt5cli/exceptions.py

@@ -9,11 +9,6 @@ from pdmt5 import Mt5RuntimeError
 if TYPE_CHECKING:
     from collections.abc import Callable
 
-try:
-    from pdmt5 import Mt5TradingError
-except ImportError:  # pragma: no cover
-    Mt5TradingError = None  # type: ignore[assignment]
-
 T = TypeVar("T")
 
 __all__ = [
@@ -26,10 +21,7 @@ __all__ = [
     "normalize_mt5_exception",
 ]
 
-_RECOVERABLE_MT5_ERRORS: tuple[type[BaseException], ...] = (
-    *([Mt5TradingError] if Mt5TradingError is not None else []),  # type: ignore[misc]
-    Mt5RuntimeError,
-)
+_RECOVERABLE_MT5_ERRORS: tuple[type[BaseException], ...] = (Mt5RuntimeError,)
 
 
 class Mt5CliError(Exception):
@@ -55,7 +47,7 @@ def is_recoverable_mt5_error(exc: BaseException) -> bool:
         exc: Exception raised by MT5 or pdmt5.
 
     Returns:
-        True for ``Mt5RuntimeError`` and ``Mt5TradingError`` (if available).
+        True for ``Mt5RuntimeError``.
     """
     return isinstance(exc, _RECOVERABLE_MT5_ERRORS)
 
@@ -67,11 +59,9 @@ def normalize_mt5_exception(exc: BaseException) -> Mt5CliError:
         exc: Original exception from MT5 or pdmt5.
 
     Returns:
-        ``Mt5ConnectionError`` for runtime failures, ``Mt5OperationError`` for
-        trading failures, or the original exception when it is not recognized.
+        ``Mt5ConnectionError`` for runtime failures, or the original exception
+        when it is not recognized.
     """
-    if Mt5TradingError is not None and isinstance(exc, Mt5TradingError):
-        return Mt5OperationError(str(exc))
     if isinstance(exc, Mt5RuntimeError):
         return Mt5ConnectionError(str(exc))
     if isinstance(exc, Mt5CliError):