redundo 0.1.0__tar.gz

redundo-0.1.0/.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,51 @@
+name: Bug report
+description: Something in redundo produced a wrong, missing, or misleading result.
+labels: ["bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for reporting this. redundo's whole design point is "never guess past a genuine unknown" -- so a case where it guessed wrong, or where its degrade-honestly behavior is confusing, is exactly the kind of bug report that matters most.
+
+  - type: dropdown
+    id: component
+    attributes:
+      label: Where does this happen?
+      options:
+        - redundo adapt (a specific source: openinference, claude-code, cowork, openclaw)
+        - redundo analyze (classification, coverage, report output)
+        - redundo collect
+        - CLI / packaging
+        - Documentation
+        - Not sure
+    validations:
+      required: true
+
+  - type: textarea
+    id: what-happened
+    attributes:
+      label: What happened?
+      description: What you expected vs. what you actually got.
+    validations:
+      required: true
+
+  - type: textarea
+    id: repro
+    attributes:
+      label: Minimal reproduction
+      description: >
+        A small trace (JSONL for `analyze`, or a captured OTLP batch for `adapt`) that
+        reproduces this, plus the exact command you ran. Redact any real prompt/tool
+        content first -- content_hash exists so you never have to share raw content to
+        report a bug.
+      render: shell
+    validations:
+      required: true
+
+  - type: input
+    id: version
+    attributes:
+      label: redundo version
+      description: Output of `pip show redundo` (the Version line), or the commit/tag you installed from.
+    validations:
+      required: true

redundo-0.1.0/.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1 @@
+blank_issues_enabled: true

redundo-0.1.0/.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,42 @@
+name: Feature request
+description: A new source, a new analysis, or a change to adapt/analyze's behavior.
+labels: ["enhancement"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Before proposing a new adapter source or analysis, skim [CONTRIBUTING.md](../../CONTRIBUTING.md) --
+        both are held to specific discipline (real captured telemetry, honest coverage
+        reporting, never guessing past a genuine unknown) that shapes what a good PR
+        for either looks like.
+
+  - type: dropdown
+    id: kind
+    attributes:
+      label: What kind of change is this?
+      options:
+        - New adapter source (a new agent framework's OTLP)
+        - New analysis (something other than redundant-call detection)
+        - Change to an existing source or analysis
+        - CLI / packaging
+        - Other
+    validations:
+      required: true
+
+  - type: textarea
+    id: problem
+    attributes:
+      label: What's the problem or gap?
+      description: What can't you do with redundo today that you want to?
+    validations:
+      required: true
+
+  - type: textarea
+    id: proposal
+    attributes:
+      label: Proposed approach
+      description: >
+        If this is a new source: what does its real OTLP/telemetry shape look like,
+        and do you have a real capture to validate against? (See CONTRIBUTING.md --
+        every source in this project was built against actual captured data, not
+        just a framework's docs.)

redundo-0.1.0/.github/pull_request_template.md

@@ -0,0 +1,10 @@
+## What changed and why
+
+<!-- The "why" matters more than the "what" here -- see CONTRIBUTING.md. -->
+
+## Checklist
+
+- [ ] `uv run pytest` passes locally
+- [ ] New behavior has test coverage (a fixture, not just a real capture -- real captures are for validation, too brittle/large to be the actual test)
+- [ ] If this touches an adapter source or the analyzer: coverage/known-gaps are still reported honestly, nothing silently guesses past an unknown
+- [ ] Docs (`README.md`, `docs/*.md`) updated if this changes documented behavior

redundo-0.1.0/.github/workflows/ci.yml

@@ -0,0 +1,29 @@
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+jobs:
+  test:
+    name: test (py${{ matrix.python-version }})
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        python-version: ["3.10", "3.11", "3.12"]
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Install uv
+        uses: astral-sh/setup-uv@v3
+        with:
+          python-version: ${{ matrix.python-version }}
+
+      - name: Install dependencies
+        run: uv sync --extra collector
+
+      - name: Run tests
+        run: uv run pytest -q

redundo-0.1.0/.github/workflows/publish.yml

@@ -0,0 +1,45 @@
+name: Publish to PyPI
+
+on:
+  release:
+    types: [published]
+
+jobs:
+  build:
+    name: Build distribution
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Install uv
+        uses: astral-sh/setup-uv@v3
+        with:
+          python-version: "3.12"
+
+      - name: Build sdist and wheel
+        run: uv build
+
+      - name: Upload build artifacts
+        uses: actions/upload-artifact@v4
+        with:
+          name: dist
+          path: dist/
+
+  publish:
+    name: Publish
+    needs: build
+    runs-on: ubuntu-latest
+    environment:
+      name: pypi
+      url: https://pypi.org/project/redundo/
+    permissions:
+      id-token: write  # required for PyPI Trusted Publishing (OIDC) -- no API token stored anywhere
+    steps:
+      - name: Download build artifacts
+        uses: actions/download-artifact@v4
+        with:
+          name: dist
+          path: dist/
+
+      - name: Publish to PyPI
+        uses: pypa/gh-action-pypi-publish@release/v1

redundo-0.1.0/.gitignore

@@ -0,0 +1,8 @@
+.venv/
+__pycache__/
+*.pyc
+.pytest_cache/
+*.egg-info/
+dist/
+build/
+.DS_Store

redundo-0.1.0/CODE_OF_CONDUCT.md

@@ -0,0 +1,64 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community 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, 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 email address,
+  without their explicit permission
+- Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Project 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 to the maintainers by opening a private security advisory or issue on
+this repository. All complaints will be reviewed and investigated promptly and
+fairly.
+
+## 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][v2.1].
+
+[homepage]: https://www.contributor-covenant.org
+[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html

redundo-0.1.0/CONTRIBUTING.md

@@ -0,0 +1,129 @@
+# Contributing
+
+By participating in this project you agree to abide by its
+[Code of Conduct](CODE_OF_CONDUCT.md).
+
+This is two packages under one name: `redundo.adapter` turns a
+specific trace source into the schema, `redundo.analyzer` runs
+analyses over that schema. They share the schema contract and nothing
+else at runtime — contribute to either independently.
+
+## Workflow
+
+- **Every change goes through a branch and a pull request against
+  `main`** — including maintainers' own changes. `main` is protected:
+  direct pushes are rejected, and CI must pass before a PR can merge.
+- **Branch names**: `fix/…` for bug fixes, `feat/…` for new sources or
+  analyses, `chore/…` for anything else (docs, CI, tooling).
+- **Bug reports and feature requests** go through the issue templates
+  (`.github/ISSUE_TEMPLATE/`) rather than an ad-hoc issue — the bug
+  report template in particular asks for a minimal reproduction (a
+  small fixture, not a real capture) and the redundo version, which is
+  most of what's needed to act on it.
+- **CI** (`.github/workflows/ci.yml`) runs the full test suite on
+  Python 3.10–3.12 for every PR. A PR that doesn't pass CI doesn't get
+  merged, no exception for "it's just docs" — the workflow itself is
+  the only thing verifying that.
+
+## Adding a new source (`redundo.adapter`)
+
+Each source lives in its own module under `src/redundo/adapter/sources/`.
+A good addition:
+
+1. **Captures real telemetry first.** Every existing source's `docs/*.md`
+   was written against actual captured OTLP JSON, not just the source's
+   published documentation — several documented behaviors turned out to
+   be wrong or incomplete once checked against real data. Do the same:
+   enable the source's telemetry, point it at a local collector (see
+   `docs/` for examples), and look at what actually comes out before
+   writing conversion logic against it.
+2. **Writes a `docs/<source>.md`** covering: how task/session grouping
+   works, what content is and isn't observable (and under which flags),
+   how tool calls and their results are represented, and a "known gaps"
+   section stating plainly what can't be recovered and why. Copy the
+   structure of an existing source doc.
+3. **Adds a detection rule** in `detect.py` — something in the data
+   itself (a span name, an attribute, a resource attribute) that
+   reliably distinguishes this source from every other one already
+   supported. If nothing does, say so in the docstring and require
+   `--source` instead of guessing.
+4. **Never fabricates content.** If a result or a piece of content isn't
+   observable, omit the record or mark it explicitly rather than
+   inventing a placeholder hash — see `hashing.py`'s module docstring and
+   any existing source's handling of unobservable content for why: a
+   placeholder hash that happens to match (or never match) another
+   record's hash reads as a real finding to everything downstream.
+5. **Tests against hand-built fixtures**, not just real captures (which
+   are convenient for validation but too large/brittle to check in) --
+   see `tests/adapter/helpers.py` for the fixture builders every existing
+   source's tests use.
+
+## Adding a new analysis (`redundo.analyzer`)
+
+The schema and ingest layer (`schema.py`, `ingest.py`) and the reporting
+infrastructure (`report.py`'s coverage plumbing, `to_text()`/`to_json()`/
+`to_html()`) are not specific to waste detection. `classify.py`,
+`cycles.py`, and the candidate-pair parts of `lineage.py` are — that's
+today's one analysis, not the whole package.
+
+A new analysis over the same schema should:
+
+1. **Reuse `load_events()` and the `Event` dataclass** — never invent a
+   parallel ingestion path. The schema is the contract every adapter
+   targets; a second analysis reading something else defeats the point
+   of having one.
+2. **Report coverage honestly**, the same way the waste analysis does:
+   what fraction of the loaded corpus this analysis can actually speak
+   to, before any headline number. See `metrics.py`'s `CoverageStats`
+   and `report.py`'s coverage lines for the pattern to follow.
+3. **Never guess past a genuine unknown.** `classify.py`'s three-signal
+   model (waste-supporting / legit-supporting / unknown, never a forced
+   binary) and its module docstring are the reference for why: a
+   confident wrong answer is worse than an honest "the trace doesn't
+   say," because the first time someone spot-checks a confident answer
+   by hand and finds it wrong, the tool stops being trusted.
+4. **Prints its rule next to its own counts**, not just a label — see
+   `RULE_TEXT` in `report.py`. A number without the rule that produced it
+   isn't checkable by anyone reading the report.
+5. **Ships with a fixture-based validation**, the same discipline
+   `tests/analyzer/fixtures/sample.jsonl` follows: hand-built traces with
+   a known, intended classification for each case your new analysis
+   distinguishes, not just real captured examples (useful for demos, too
+   brittle/large to be the actual test).
+
+## Running tests
+
+```bash
+uv sync
+uv run pytest
+```
+
+`tests/adapter/` and `tests/analyzer/` run independently — a change to
+one package's tests should never need to touch the other's.
+
+## Releasing to PyPI
+
+Publishing uses [Trusted Publishing](https://docs.pypi.org/trusted-publishers/)
+(OIDC) via GitHub Actions — no API token is stored anywhere. To cut a release:
+
+1. Bump `version` in `pyproject.toml`, merge that through the normal PR
+   workflow.
+2. Tag the merge commit `vX.Y.Z` and push the tag, or create a GitHub
+   Release directly against `main` with that tag.
+3. Publishing a GitHub Release triggers `.github/workflows/publish.yml`,
+   which builds the sdist/wheel with `uv build` and publishes them via
+   `pypa/gh-action-pypi-publish`.
+
+The PyPI project must have this repository registered as a trusted
+publisher first (PyPI account/org → Publishing settings → project name
+`redundo`, repo `CogentWizards/redundo`, workflow `publish.yml`,
+environment `pypi`) — a one-time setup step, done on pypi.org, not in
+this repo.
+
+## Reporting a documented behavior that turned out to be wrong
+
+If you've captured real telemetry from a source and it disagrees with
+what's written in `docs/`, that's a genuinely valuable bug report even
+without a fix attached — open an issue (the bug report template) with
+the captured data (redacted of any real content) or a description of
+the discrepancy.

redundo-0.1.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Cogent AI
+
+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.