project-ara 0.0.1__tar.gz

project_ara-0.0.1/.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,47 @@
+name: "🐞 Bug report"
+description: Something didn't behave as expected — wrong detection, a crash, or bad output.
+title: "[bug] "
+labels: ["bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for the report! ARA is recon-first, so the most useful thing is the **exact
+        command and its output** (use `--json` if the text rendering is the issue), plus what
+        you expected instead.
+  - type: textarea
+    id: what-happened
+    attributes:
+      label: What happened
+      description: What did you expect, and what actually occurred?
+    validations:
+      required: true
+  - type: textarea
+    id: command
+    attributes:
+      label: Command + output
+      description: The exact `uv run ara ...` command and its output (`--json` welcome).
+      render: shell
+    validations:
+      required: true
+  - type: input
+    id: machine
+    attributes:
+      label: Machine
+      description: Chip / OS (the top of `ara detect` is perfect), e.g. "Apple M4 Pro, macOS 15.7".
+    validations:
+      required: true
+  - type: input
+    id: versions
+    attributes:
+      label: ARA + Python + uv versions
+      description: Commit/version of ARA, `python3 --version`, `uv --version`.
+    validations:
+      required: false
+  - type: textarea
+    id: extra
+    attributes:
+      label: Anything else
+      description: Logs, screenshots, or context that might help.
+    validations:
+      required: false

project_ara-0.0.1/.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,8 @@
+blank_issues_enabled: true
+contact_links:
+  - name: Contributing guide
+    url: https://github.com/willsarg/project-ara/blob/main/CONTRIBUTING.md
+    about: Setup, conventions, the read-only/advisory rules, and how to land a change.
+  - name: Security report (private)
+    url: https://github.com/willsarg/project-ara/security
+    about: Please report vulnerabilities privately, not as a public issue.

project_ara-0.0.1/.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,38 @@
+name: "✨ Feature request"
+description: Suggest a command, recon coverage, a backend, or an improvement.
+title: "[feat] "
+labels: ["enhancement"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Ideas welcome — especially **recon coverage** (a tool/app/model store/interpreter ARA
+        doesn't know about), **new backends** (e.g. CUDA), or sharper readouts. Please keep
+        ARA's boundaries in mind ([AGENTS.md](https://github.com/willsarg/project-ara/blob/main/AGENTS.md)):
+        recon is read-only, `profile` is consent-gated, and ARA stays advisory.
+  - type: dropdown
+    id: area
+    attributes:
+      label: Area
+      options:
+        - New command
+        - Recon coverage (tool / app / model store / interpreter)
+        - New backend (e.g. CUDA)
+        - Output / UX
+        - Other
+    validations:
+      required: true
+  - type: textarea
+    id: problem
+    attributes:
+      label: The problem / what's missing
+      description: What can't you do today, or what does ARA get wrong or fail to surface?
+    validations:
+      required: true
+  - type: textarea
+    id: proposal
+    attributes:
+      label: Proposed behavior
+      description: What should ARA do? If it's coverage, how would ARA detect it reliably?
+    validations:
+      required: false

project_ara-0.0.1/.github/dependabot.yml

@@ -0,0 +1,21 @@
+# Weekly Dependabot updates, each grouped into a single low-noise PR:
+#   - github-actions: keep the SHA-pinned actions fresh (pins otherwise go stale + miss security fixes)
+#   - uv: keep the Python deps (pyproject.toml + uv.lock) current
+# https://docs.github.com/code-security/dependabot
+version: 2
+updates:
+  - package-ecosystem: github-actions
+    directory: /
+    schedule:
+      interval: weekly
+    groups:
+      actions:
+        patterns: ["*"]      # one combined PR for all action bumps
+
+  - package-ecosystem: uv
+    directory: /
+    schedule:
+      interval: weekly
+    groups:
+      python:
+        patterns: ["*"]      # one combined PR for all Python dep bumps

project_ara-0.0.1/.github/pull_request_template.md

@@ -0,0 +1,35 @@
+<!-- Thanks for contributing! Keep PRs focused on a single change. -->
+
+## Summary
+
+<!-- What does this change and why? -->
+
+Related issue: <!-- e.g. Fixes #N -->
+
+## Type of change
+
+- [ ] Bug fix
+- [ ] New feature
+- [ ] Recon coverage (new tool / app / model store / interpreter)
+- [ ] New backend
+- [ ] Docs only
+- [ ] Refactor / cleanup (no behavior change)
+
+## ARA's rules (see [AGENTS.md](../AGENTS.md))
+
+- [ ] **Recon stays read-only** — no new code path under `detect`/`status`/`python`/`apps`/`mlx`
+      stresses the machine, loads a model, or mutates state.
+- [ ] **`profile` stays consent-gated** — it only measures/downloads with explicit opt-in.
+- [ ] **Advisory, not destructive** — nothing here runs or prescribes a state-mutating command.
+- [ ] **Core stays engine-free** — no hardware-specific import outside a lazily-loaded backend.
+- [ ] Reports the **user's** environment, not ARA's (venv stripped where relevant).
+
+## Conventions
+
+- [ ] `uv` only (no `--break-system-packages`); HF CLI is `hf`.
+- [ ] Tests added/updated; `uv run pytest` green at **100%** statement + branch coverage.
+- [ ] New curated-catalog entries note how they were verified.
+
+## Evidence
+
+<!-- Paste relevant command output (e.g. `ara apps` before/after), and note the machine. -->

project_ara-0.0.1/.github/workflows/publish.yml

@@ -0,0 +1,75 @@
+# Publish project-ara to PyPI via Trusted Publishing (OIDC) — no API token stored.
+# Fires when a version tag (v*) is pushed. The PyPI side is a "trusted publisher" registered at
+# https://pypi.org/manage/account/publishing/ bound to: owner willsarg, repo project-ara,
+# workflow publish.yml, environment pypi. See https://docs.pypi.org/trusted-publishers/.
+#
+# NOTE: version is static in pyproject.toml — the first build step fails if the tag doesn't match it.
+#
+# Security hardening: deny-all token by default (each job opts into the minimum), actions pinned to
+# full commit SHAs (mutable tags are a supply-chain risk), checkout credentials not persisted,
+# id-token:write scoped to the publish job alone, environment binding, per-job timeouts.
+name: Publish to PyPI
+
+on:
+  push:
+    tags:
+      - "v*"
+
+permissions: {}            # deny-all at the top; each job opts into only what it needs
+
+jobs:
+  # Tests gate the release (test → build → publish): a v* tag runs the cross-OS suite first via the
+  # shared test.yml, and build/publish only proceed if every OS passes.
+  test:
+    uses: ./.github/workflows/test.yml
+    permissions:
+      contents: read
+
+  build:
+    needs: test            # no build unless tests pass on all OSes
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    permissions:
+      contents: read       # checkout only
+    steps:
+      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
+        with:
+          persist-credentials: false
+      - name: Verify tag matches pyproject version
+        env:
+          TAG: ${{ github.ref_name }}          # e.g. v0.0.2 — via env, never inlined into the script
+        run: |
+          file_version="$(python3 -c "import tomllib; print(tomllib.load(open('pyproject.toml','rb'))['project']['version'])")"
+          tag_version="${TAG#v}"               # strip the leading v
+          echo "tag=$TAG (->$tag_version)  pyproject=$file_version"
+          if [ "$tag_version" != "$file_version" ]; then
+            echo "::error::tag $TAG does not match pyproject.toml version $file_version — bump the version (or fix the tag) so they line up, then re-tag."
+            exit 1
+          fi
+      - name: Install uv
+        uses: astral-sh/setup-uv@fac544c07dec837d0ccb6301d7b5580bf5edae39 # v8.2.0
+        with:
+          python-version: "3.12"
+      - name: Build sdist + wheel
+        run: uv build                       # uses the declared hatchling backend
+      - name: Upload dist artifact
+        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
+        with:
+          name: dist
+          path: dist/
+
+  publish:
+    needs: build
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+    environment: pypi      # bind to the GitHub Environment the PyPI publisher trusts
+    permissions:
+      id-token: write      # OIDC token for Trusted Publishing — the ONLY elevated scope
+    steps:
+      - name: Download dist artifact
+        uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
+        with:
+          name: dist
+          path: dist/
+      - name: Publish to PyPI
+        uses: pypa/gh-action-pypi-publish@cef221092ed1bacb1cc03d23a2d87d1d172e277b # v1.14.0

project_ara-0.0.1/.github/workflows/test.yml

@@ -0,0 +1,39 @@
+# The test suite, run on all three OSes — primarily to catch POSIX/path/filesystem differences
+# (the project has Windows-specific code paths). Runs the mocked unit suite + 100% coverage gate
+# (both baked into the default `pytest` in pyproject.toml). Integration tests (`-m integration`) are
+# hardware-gated and stay manual on the real boxes.
+#
+# Two entry points:
+#   - workflow_call: the release pipeline (publish.yml) calls this so a v* tag is gated on tests.
+#   - workflow_dispatch: run it by hand from the Actions tab for on-demand cross-platform feedback.
+#
+# Hardening: read-only token, actions pinned to commit SHAs, checkout creds not persisted, locked
+# deps, per-job timeout. The run steps are single uv commands, so they work in bash (Linux/macOS)
+# and PowerShell (Windows) unchanged — no shell-specific syntax.
+name: Test
+
+on:
+  workflow_call:
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+jobs:
+  test:
+    strategy:
+      fail-fast: false           # show every OS's result, not just the first failure
+      matrix:
+        os: [ubuntu-latest, windows-latest, macos-latest]
+    runs-on: ${{ matrix.os }}
+    timeout-minutes: 20
+    steps:
+      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
+        with:
+          persist-credentials: false
+      - uses: astral-sh/setup-uv@fac544c07dec837d0ccb6301d7b5580bf5edae39 # v8.2.0
+        with:
+          python-version: "3.12"
+          enable-cache: true
+      - run: uv sync --frozen --group dev
+      - run: uv run pytest         # unit suite + 100% coverage gate

project_ara-0.0.1/.gitignore

@@ -0,0 +1,232 @@
+# 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
+
+# Redis
+*.rdb
+*.aof
+*.pid
+
+# RabbitMQ
+mnesia/
+rabbitmq/
+rabbitmq-data/
+
+# ActiveMQ
+activemq-data/
+
+# 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/
+# Temporary file for partial code execution
+tempCodeRunnerFile.py
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# Marimo
+marimo/_static/
+marimo/_lsp/
+__marimo__/
+
+# Streamlit
+.streamlit/secrets.toml
+
+# Local agent/session artifacts — archive useful summaries in the private vault, not the repo
+.superpowers/
+superpowers/
+.playwright-mcp/
+
+# macOS local metadata
+.DS_Store
+**/.DS_Store
+mutants/
+.mutmut-cache
+
+# Claude Code local agent workspace (not part of the project)
+.claude/

project_ara-0.0.1/.python-version

@@ -0,0 +1 @@
+3.12

project_ara-0.0.1/AGENTS.md

@@ -0,0 +1,115 @@
+# AGENTS.md — purpose, boundaries, and conventions for ARA
+
+This is the source of truth for *what ARA is and how to work on it*. Read it before
+contributing (human or agent). [CONTRIBUTING.md](./CONTRIBUTING.md) covers the human
+workflow (setup, landing a change); this covers the **why** and the **rules**.
+
+## What ARA is
+
+**Project ARA — "AI Runs Anywhere."** A tool you reach for to **honestly assess any machine
+with a Python runtime for AI workloads**, then run local models safely on whatever hardware
+is present. Apple Silicon (MLX), NVIDIA (CUDA), and any CPU all run models today; recon works everywhere.
+
+### The three rules (the invariant core)
+
+ARA's mission — *"AI Runs Anywhere: safely, reliably, and accurately — train, run, and govern AI
+workloads on any infrastructure"* — **is** three numbered rules. Every change, in every part of the
+system, answers to all three. Canonical statement: the private vault's `ARA - Product` note.
+
+1. **Safety** — *don't crash the system.* Never exceed the memory wall; run right up to the safe
+   edge and no further. In ARA's core this means **recon is read-only** and **`characterize` is
+   consent-gated** (see Hard rules); the engines (wmx/wcx) enforce the wall when they measure and
+   launch.
+2. **Reliability** — *every component is properly tested.* `fail_under = 100` (statement + branch);
+   new code lands with tests (see Conventions). A component you can't trust isn't shipped.
+3. **Accuracy** — *report true data; never lie to the user.* For deterministic recon **and**
+   non-deterministic model output alike: report the user's *real* environment, never ARA's
+   internals; never claim something ARA didn't observe; `unknown` is a first-class answer
+   (distinguish measured / curated / unknown); never surface a model's hallucination as fact.
+
+### ARA-specific design values
+
+- **Well-scoped tools.** Each command does one clear job with a predictable boundary:
+  - `detect` — **read-only recon**. Observes the machine; never stresses, benchmarks, or
+    loads an ML engine.
+  - `status` — running AI/ML processes, right now.
+  - `python` — every interpreter + its AI libraries + install cautions.
+  - `apps` — installed AI/ML apps, versions, source, and Homebrew drift.
+  - `mlx` — the MLX ecosystem + Apple readiness.
+  - `profile` — **engine-free** analytic capability assessment: estimates the safe memory
+    budget from recon facts; never loads an engine or a model.
+  - `characterize` — **the command that measures**: opt-in; crosses the seam into the engine to
+    find a model's real safe context ceiling (refusing before it risks the memory wall).
+  - `recommend` — ranks cached models that fit this machine's budget, by estimated usable context.
+  - `run` — governed one-shot inference, capped under the measured safe ceiling (CPU · MLX · CUDA).
+  - `models` / `search` — catalog cached models (with measured ceilings) / search the HF Hub.
+  - `hf login` / `logout` / `status` — manage the Hugging Face token (needed for gated models). An
+    **action** command (writes the standard HF token store, so every fetch + worker reads it), not
+    recon; verifies via the Hub and never prints the token.
+- **Broad compatibility.** Cover the open-source AI ecosystem widely — engines (MLX,
+  llama.cpp, Ollama, LM Studio, vLLM), model stores (HF, Ollama, LM Studio, Jan, GPT4All),
+  frameworks (PyTorch, transformers, TensorFlow), and apps — not one vendor's corner.
+
+## The architecture boundary (don't break this)
+
+- **Pure-Python core, swappable backend adapters.** The core (`ara/detect.py`, `cli.py`,
+  recon modules) must **never import a hardware-specific engine**. Backends live behind a
+  registry and are loaded lazily — only the one chosen for the machine.
+- **Apple backend wraps [`wmx-suite`](https://github.com/willsarg/wmx-suite).** The engine
+  import happens *inside* the adapter's functions, not at module load — so nothing
+  MLX-shaped loads until ARA actually runs the engine.
+- **Engines install on demand, not as dependencies.** The hardware engine is **not** in
+  `pyproject.toml`. ARA probes the machine and installs the matched suite at runtime via
+  `ara install` (`ara/engines.py` is the catalog + `uv pip install git+<spec>` logic). This
+  keeps the core universal, the lock engine-free, and `uv sync` identical on every OS — and
+  never ships MLX to a non-Apple machine. `--engine {wmx|wcx|cpu|auto}` is the consent surface
+  (the flag itself authorizes the install, so it stays scriptable).
+
+## Hard rules
+
+These are how **Rule #1 (Safety)** and **Rule #3 (Accuracy)** are enforced in the recon core:
+
+- **Recon is read-only.** Nothing under `detect`/`status`/`python`/`apps`/`mlx` may stress
+  the machine, load a model, or mutate state.
+- **Measuring is consent-gated.** `characterize` is the only command that loads an engine and a
+  model (downloading weights on demand) — it runs only with explicit user opt-in. `profile` stays
+  engine-free and read-only.
+- **Advisory, never destructive.** ARA surfaces facts and considerations. It does **not**
+  run or prescribe state-mutating commands on the user's behalf. (A flag may *describe* a
+  fix; it must not tell the user to run something that silently destroys state.)
+- **Honest about the user's environment, not ARA's.** When probing tools/interpreters, strip
+  ARA's own virtualenv so results reflect what the *user* has, not ARA's bundled deps.
+
+## Conventions
+
+- **`uv` only.** No `pip install --break-system-packages`. The HF CLI is `hf`, not the
+  deprecated `huggingface-cli`.
+- **Tests are the bar.** `fail_under = 100` (statement + branch). New code lands with tests.
+  The suite runs **without** `wmx-suite` on purpose — it proves the core stays engine-free;
+  the seam is covered via a fake `wmx_suite`.
+- **Planning/design docs live in the private vault, not the repo.** This repo is code +
+  standard community files. Don't add design specs or logs here.
+- **Write portable; claim only what's tested.** Shared layers (the engine env, worker IPC,
+  paths) must be OS-agnostic — use `pathlib`/`os.path`, branch interpreter/venv layout on
+  `os.name` (`Scripts\python.exe` vs `bin/python`), keep OS-specific recon (sysctl, Homebrew
+  paths) behind a platform guard. ARA is developed on macOS (Apple Silicon) and tested green on
+  macOS (CPU + MLX), Windows (CPU + CUDA, RTX 2070), and Linux (CPU); **claim a platform only once
+  the suite is green there** — CUDA-on-Linux shares the Windows code path but isn't claimed yet
+  (no NVIDIA-on-Linux box has run it).
+
+## License & AI agents (Apache 2.0)
+
+Project ARA is licensed **Apache-2.0** (`LICENSE`, `NOTICE`). Abide by it in both directions.
+
+**Contributing here (inbound — Apache §5, inbound = outbound; no CLA/DCO):**
+- All contributions are under Apache-2.0.
+- Add only original code, or code under an Apache-2.0-compatible permissive license (MIT/BSD/ISC/Apache-2.0); preserve its copyright/license and record third-party components in `NOTICE`.
+- Never introduce GPL/LGPL/AGPL, proprietary, or unknown-provenance code.
+- Start every new source file with: `# SPDX-License-Identifier: Apache-2.0` and `# Copyright 2026 Will Sarg`.
+- Do not alter or remove `LICENSE`, `NOTICE`, or existing SPDX headers.
+
+**Cloning / forking / redistributing (outbound — Apache §4):**
+- Keep `LICENSE` and `NOTICE` intact in any copy or fork.
+- Retain all SPDX headers and copyright notices in files you carry.
+- State significant changes you make.
+- You may relicense *your own* additions; the Apache-2.0-covered files stay Apache-2.0.

project_ara-0.0.1/CLAUDE.md

@@ -0,0 +1,2 @@
+See [AGENTS.md](./AGENTS.md) for ARA's purpose, architecture boundary, hard rules, and
+conventions. It's the source of truth for working on this project.

project_ara-0.0.1/CODE_OF_CONDUCT.md

@@ -0,0 +1,58 @@
+# Code of Conduct
+
+## Our Pledge
+
+We as contributors and maintainers pledge to make participation in Project ARA a
+harassment-free experience for everyone, regardless of age, body size, visible or invisible
+disability, ethnicity, sex characteristics, gender identity and expression, level of
+experience, education, socio-economic status, nationality, personal appearance, race, caste,
+color, religion, or sexual identity and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming, diverse,
+inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment:
+
+- Demonstrating empathy and kindness toward other people
+- Being respectful of differing opinions, viewpoints, and experiences
+- Giving and gracefully accepting constructive feedback
+- Accepting responsibility and apologizing to those affected by our mistakes, and learning
+  from the experience
+- Focusing on what is best not just for us as individuals, but for the overall community
+
+Examples of unacceptable behavior:
+
+- The use of sexualized language or imagery, and sexual attention or advances of any kind
+- Trolling, insulting or derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic address, without
+  explicit permission
+- Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Enforcement Responsibilities
+
+Maintainers are responsible for clarifying and enforcing our standards of acceptable behavior
+and will take appropriate and fair corrective action in response to any behavior that they
+deem inappropriate, threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when an individual
+is officially representing the community in public spaces.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported via
+GitHub's private messaging or through the repo's
+[Security tab](https://github.com/willsarg/project-ara/security). All reports will be
+reviewed and investigated promptly and fairly. Maintainers are obligated to respect the
+privacy and security of the reporter.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.1,
+available at <https://www.contributor-covenant.org/version/2/1/code_of_conduct.html>.
+
+[homepage]: https://www.contributor-covenant.org