elasticdash-sdk 0.1.2a2__tar.gz

elasticdash_sdk-0.1.2a2/.claude/settings.local.json

@@ -0,0 +1,11 @@
+{
+  "permissions": {
+    "allow": [
+      "Bash(python:*)",
+      "Bash(xxd \"/Users/jiangjiahao/Documents/GitHub/ElasticDash-MCP/mcp-server/server.ts\")",
+      "Bash(grep:*)",
+      "Bash(pip index:*)",
+      "Bash(pip install:*)"
+    ]
+  }
+}

elasticdash_sdk-0.1.2a2/.github/copilot-instructions.md

@@ -0,0 +1,67 @@
+Repository Steering & AI Contributor Guide
+=========================================
+
+Purpose
+-------
+Provide a clear, repeatable workflow for coding AI agents that manage and modify this repository while keeping a human in the approval loop at all times.
+
+High-Level Expectations
+-----------------------
+- Act as a cautious collaborator: minimize churn, avoid surprises, and preserve user-owned changes.
+- Default to small, reviewable increments; avoid speculative or wide-ranging edits without explicit direction.
+- Keep communication concise, factual, and action-oriented.
+- You are in macOS, so run `source .venv/bin/activate` to use the virtual environment if it exists; avoid global package installs.
+
+Mandatory Plan & Approval Gate
+------------------------------
+- Before making any code or docs changes, **draft a plan** describing scope, files to touch, and intended steps. The plan should be saved in the markdown file './.temp/plan.md'.
+- **Request human approval** for the plan and wait until approval is granted before proceeding with any edits.
+- If new information or unexpected changes require a different approach, **update the existing plan**, highlight the differences, and request approval again.
+- If an entirely new plan is required, **remove the old plan**, present the new one, and seek approval before continuing.
+
+Change Execution Workflow (post-approval)
+-----------------------------------------
+1. Re-read relevant files in batches to refresh context and confirm nothing diverged from the approved plan.
+2. Implement changes exactly as approved; flag any deviations and pause for guidance.
+3. Keep edits minimal and localized; avoid drive-by refactors unless specifically requested.
+4. Add or adjust tests when behavior changes; prefer `pytest` in `tests/` for coverage.
+5. Run applicable checks (formatters/linters/tests) when possible; report what was run and any results.
+6. Summarize outcomes with file and line references, describe side effects/risks, and propose next steps if needed.
+
+Coding & Repo Practices
+-----------------------
+- Python style: favor readability; add short comments only for non-obvious logic.
+- Environments: use the repo’s virtualenv if present (`.venv`), avoid global installs.
+- Testing: prefer `pytest`; keep new tests fast and deterministic.
+- Documentation: update relevant docs when altering behavior or interfaces.
+- Avoid destructive git operations; never revert user changes unless explicitly instructed.
+
+Communication Norms
+-------------------
+- Ask for clarification only when necessary; suggest sensible defaults to accelerate decisions.
+- When presenting changes, lead with findings/impacts before summaries; include risks and testing status.
+- Keep responses concise and scoped to the request; no excessive formatting.
+
+Plan Template (copy/paste)
+--------------------------
+- Goal: what will change and why.
+- Scope: bullets of the change boundaries; note any out-of-scope areas.
+- Files/areas to touch: list expected files or directories.
+- Steps: ordered list of actions with checkboxes (e.g., - [ ] Step 1); keep it short.
+- Risks/unknowns: call out uncertainties or potential impacts.
+- Testing: what you plan to run (e.g., `pytest tests/...` or "none").
+- Approval: explicitly request human approval before execution.
+
+Example
+-------
+- Goal: Add plan template section to steering doc for AI agents.
+- Scope: Update .github/copilot-instructions.md only; no code changes.
+- Files/areas to touch: .github/copilot-instructions.md.
+- Steps: 
+  - [ ] Re-read current guide; 
+  - [ ] Append plan template and example; 
+  - [ ] Keep tone concise; 
+  - [ ] Summarize edit.
+- Risks/unknowns: none.
+- Testing: none (docs only).
+- Approval: request and wait for human approval before editing.

elasticdash_sdk-0.1.2a2/.gitignore

@@ -0,0 +1,209 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[codz]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py.cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.lock
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#uv.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+#poetry.lock
+#poetry.toml
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#   pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
+#   https://pdm-project.org/en/latest/usage/project/#working-with-version-control
+#pdm.lock
+#pdm.toml
+.pdm-python
+.pdm-build/
+
+# pixi
+#   Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
+#pixi.lock
+#   Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
+#   in the .venv directory. It is recommended not to include this directory in version control.
+.pixi
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.envrc
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#  and can be added to the global gitignore or merged into this file.  For a more nuclear
+#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
+#.idea/
+
+# Abstra
+# Abstra is an AI-powered process automation framework.
+# Ignore directories containing user credentials, local state, and settings.
+# Learn more at https://abstra.io/docs
+.abstra/
+
+# Visual Studio Code
+#  Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore 
+#  that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
+#  and can be added to the global gitignore or merged into this file. However, if you prefer, 
+#  you could uncomment the following to ignore the entire vscode folder
+# .vscode/
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# Cursor
+#  Cursor is an AI-powered code editor. `.cursorignore` specifies files/directories to
+#  exclude from AI features like autocomplete and code analysis. Recommended for sensitive data
+#  refer to https://docs.cursor.com/context/ignore-files
+.cursorignore
+.cursorindexingignore
+
+# Marimo
+marimo/_static/
+marimo/_lsp/
+__marimo__/
+
+.temp/

elasticdash_sdk-0.1.2a2/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 ElasticDash
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.