stackvitals 0.1.2__tar.gz → 0.1.4__tar.gz

stackvitals-0.1.4/.github/ISSUE_TEMPLATE/bug.yml

@@ -0,0 +1,56 @@
+name: Bug report
+description: Something in StackVitals is wrong or broken
+labels: ["bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for reporting. A wrong verdict or number is a bug too, and the most useful kind.
+        For a security problem, don't open an issue: use the **Security** tab's private reporting instead.
+  - type: textarea
+    id: what
+    attributes:
+      label: What happened
+      description: What you did, what you expected, and what happened instead.
+    validations:
+      required: true
+  - type: dropdown
+    id: where
+    attributes:
+      label: Where
+      options:
+        - The Action (workflow run, PR comment, verdict check)
+        - The web app (dashboard)
+        - The command line (stackvitals ...)
+        - The MCP server (an AI agent)
+        - Setup (stackvitals init or the app's Setup page)
+        - The docs
+    validations:
+      required: true
+  - type: input
+    id: version
+    attributes:
+      label: StackVitals version
+      description: "`pip show stackvitals` shows it. For the Action, say if you use `@v0` or a pinned tag."
+      placeholder: "0.1.4"
+    validations:
+      required: true
+  - type: dropdown
+    id: visibility
+    attributes:
+      label: Repo
+      options:
+        - Public
+        - Private
+        - Not about a repo
+  - type: input
+    id: link
+    attributes:
+      label: A link we can look at
+      description: The workflow run, pull request or app page, if the repo is public. Leave out anything private.
+  - type: textarea
+    id: logs
+    attributes:
+      label: Job summary or error output
+      description: Paste the relevant part. Remove tokens, private names and anything you don't want public.
+      render: text

stackvitals-0.1.4/.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,8 @@
+blank_issues_enabled: true
+contact_links:
+  - name: Ask a question
+    url: https://github.com/stackvitals/stackvitals/discussions/categories/q-a
+    about: How to set something up or read a number. Discussions are the best place for questions.
+  - name: Report a security problem
+    url: https://github.com/stackvitals/stackvitals/security/advisories/new
+    about: Privately, through GitHub's reporting form. Please don't open a public issue.

stackvitals-0.1.4/.github/ISSUE_TEMPLATE/feature.yml

@@ -0,0 +1,39 @@
+name: Feature request
+description: Something StackVitals should do, or do differently
+labels: ["enhancement"]
+body:
+  - type: textarea
+    id: problem
+    attributes:
+      label: The problem
+      description: What you're trying to find out or get done, and what makes it hard today.
+    validations:
+      required: true
+  - type: textarea
+    id: idea
+    attributes:
+      label: What would help
+      description: What you'd like StackVitals to show or do. A rough idea is fine.
+    validations:
+      required: true
+  - type: dropdown
+    id: module
+    attributes:
+      label: Area
+      options:
+        - CI Health
+        - Team Flow and Pull Requests
+        - Delivery and DORA
+        - Insights
+        - Dependencies
+        - Community
+        - Portal
+        - The web app
+        - The command line or MCP server
+        - Setup and integrations
+        - Something else
+  - type: textarea
+    id: else
+    attributes:
+      label: Anything else
+      description: Tools you use for this today, links, or examples.

stackvitals-0.1.4/.github/pull_request_template.md

@@ -0,0 +1,15 @@
+## What this changes
+
+<!-- What changes for someone using StackVitals, in a sentence or two. Link the issue if there is one. -->
+
+## How it was checked
+
+- [ ] Tests pass: `uv run --extra dev pytest tests -q`
+- [ ] If the web app changed: `cd web && npm run build && npm test`, and the rebuilt `src/stackvitals/web/` is committed
+- [ ] If a rule behind a verdict or number changed: its entry in `bench/accuracy/registry.json` and the regenerated
+      docs (`python bench/accuracy/summary.py`)
+- [ ] If it reaches a new host or needs a new permission: said so below
+
+## Anything reviewers should know
+
+<!-- Trade-offs, follow-ups, or what you weren't sure about. -->

stackvitals-0.1.4/.github/workflows/pages.yml

@@ -0,0 +1,44 @@
+name: Demo site
+# Publishes the landing page and the app's example-data demo to GitHub Pages. The site is static and demo-only: its
+# pages may fetch nothing but their own files, so there is no API or backend behind it to call or overload.
+on:
+  release:
+    types: [published]
+  push:
+    branches: [main]
+    paths: ["src/stackvitals/web/**", "src/stackvitals/site.py"]
+  workflow_dispatch:
+permissions: {}
+concurrency:
+  group: pages
+  cancel-in-progress: false
+jobs:
+  build:
+    if: github.repository == 'stackvitals/stackvitals'
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+    permissions:
+      contents: read
+    steps:
+      - uses: actions/checkout@fbc6f3992d24b796d5a048ff273f7fcc4a7b6c09 # v5.1.0
+        with:
+          persist-credentials: false
+      - uses: astral-sh/setup-uv@c18668ad3cf93ea998bef934396af7bb5c839dc7 # v10.2.0
+      - name: Build the demo-only site
+        run: uv run --no-dev stackvitals site build --out _site --demo-only
+      - uses: actions/upload-pages-artifact@fc324d3547104276b827a68afc52ff2a11cc49c9 # v5.0.0
+        with:
+          path: _site
+  deploy:
+    needs: build
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+    permissions:
+      pages: write
+      id-token: write   # Pages checks the deployment with GitHub's OIDC token
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    steps:
+      - id: deployment
+        uses: actions/deploy-pages@368f82528645a54fb793d4d04e342629a3f51346 # v5.0.1

{stackvitals-0.1.2 → stackvitals-0.1.4}/CHANGELOG.md

@@ -1,5 +1,33 @@
 # Changelog
 
+## 0.1.4 (2026-10-31)
+
+- PR verdicts catch more failures a change causes (from user feedback):
+  - a failure whose flakes in the last 30 days all came from this same pull request reads **New**, not likely flaky: a
+    race the change added fails now and then and passes on a re-run;
+  - a likely flake that fails on this pull request far more often than on the default branch (2 or more failures, under
+    a 5% chance at main's rate) reads **New**: the change made it worse;
+  - a likely flake shows its failure rate on the default branch; a first flaky-looking failure of a check that passed
+    every recent default-branch run says so;
+  - when a failure blamed on the change, or one of those checks, passes on a re-run of the same commit, the comment
+    says a green re-run doesn't clear it, instead of "CI is passing now".
+  These rules are new and not yet measured on labelled failures; [rules.md](docs/rules.md) says so.
+- A public demo site, https://stackvitals.github.io/stackvitals/, built with `stackvitals site build --demo-only`: it
+  fetches nothing outside itself, and its setup links point at the README. The landing page uses the app's font.
+- `glama.json`, so the Glama listing of the MCP server is maintained by the project.
+
+## 0.1.3 (2026-10-31)
+
+- The app's About page and the project site say Apache 2.0 (they said MIT); the site shows the cube logo and the
+  one-command setup.
+- The app's Setup page and Help give `stackvitals init owner/repo` as the terminal way to set a repo up.
+- PyPI lists the project's links (home, docs, source, issues, changelog).
+- Docs: the install page says how to get the command; guides, quickstart and modules lead with `stackvitals init`;
+  contradictions fixed (golden paths, GitLab, GitHub Enterprise Server, sign-in, private repos' CI runs, cycle-time
+  phases); the PR verdicts are a table; the settings page says which switches are on by default; the architecture
+  diagrams list every trigger and show Portal running from the org's repo; a release checklist with the real steps.
+- A code of conduct (Contributor Covenant 2.1), with reports through the repository's private reporting form.
+
 ## 0.1.2 (2026-10-31)
 
 - `stackvitals init owner/repo` sets StackVitals up in one command: commits the workflow (or opens a pull request), follows

stackvitals-0.1.4/CODE_OF_CONDUCT.md

@@ -0,0 +1,113 @@
+# 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, 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 for our community include:
+
+* 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 include:
+
+* 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
+
+Community leaders 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.
+
+Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits,
+issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for
+moderation decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when an individual is officially
+representing the community in public spaces. Examples of representing our community include using an official e-mail
+address, posting via an official social media account, or acting as an appointed representative at an online or
+offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders
+responsible for enforcement privately, through GitHub's private reporting form for this repository: open the
+**Security** tab of [stackvitals/stackvitals](https://github.com/stackvitals/stackvitals/security), choose **Report a
+vulnerability**, and start the title with "Conduct:". Only the maintainers can read it. You can also use GitHub's
+[Report content](https://docs.github.com/en/communities/maintaining-your-safety-on-github/reporting-abuse-or-spam)
+on any comment, issue or pull request. All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they
+deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the
+community.
+
+**Consequence**: A private, written warning from community leaders, providing clarity around the nature of the
+violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series of actions.
+
+**Consequence**: A warning with consequences for continued behavior. No interaction with the people involved,
+including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels like social media. Violating these
+terms may lead to a temporary or permanent ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a
+specified period of time. No public or private interaction with the people involved, including unsolicited
+interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to
+a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate
+behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within the community.
+
+## 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].
+
+Community Impact Guidelines were inspired by
+[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
+
+For answers to common questions about this code of conduct, see the FAQ at
+[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at
+[https://www.contributor-covenant.org/translations][translations].
+
+[homepage]: https://www.contributor-covenant.org
+[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
+[Mozilla CoC]: https://github.com/mozilla/diversity
+[FAQ]: https://www.contributor-covenant.org/faq
+[translations]: https://www.contributor-covenant.org/translations

{stackvitals-0.1.2 → stackvitals-0.1.4}/CONTRIBUTING.md

@@ -1,7 +1,7 @@
 # Contributing
 
 Thanks for helping. StackVitals is small enough that one person can read any part of it in an afternoon; please
-keep it that way.
+keep it that way. Everyone taking part follows the [Code of Conduct](CODE_OF_CONDUCT.md).
 
 ## Set up
 
@@ -15,9 +15,23 @@ uv run --extra dev pytest tests -q
 
 The tests need no token and no network. [docs/architecture.md](docs/architecture.md) explains how the parts fit.
 
+**The web app** is TypeScript in `web/`, built into `src/stackvitals/web/app/`, and the built files are committed
+(they ship in the package). After changing it:
+
+```
+cd web
+npm ci
+npm run build
+npm test
+```
+
+Commit `web/` and the rebuilt `src/stackvitals/web/` together; a test fails when the build is out of date.
+[web/README.md](web/README.md) explains its layout and the browser tests (`npm run e2e`).
+
 ## What a good change looks like
 
-- **A bug:** a failing test first, in the `tests/test_flow_<area>.py` file for that area, then the fix.
+- **A bug:** a failing test first, then the fix. Task-sized tests go in `tests/local/`; a test that guards a real
+  bug or finding for a whole flow goes in the `tests/test_flow_<area>.py` file for that area.
 - **A new rule or a changed one** (anything that decides a verdict or a number people see): add or update its entry in
   [bench/accuracy/registry.json](bench/accuracy/registry.json) with what it was tuned on, what it was checked on and
   the bar, check it on public data the rule never saw, then run `python bench/accuracy/summary.py` to regenerate
@@ -34,7 +48,7 @@ The tests need no token and no network. [docs/architecture.md](docs/architecture
 - Code reads like the code around it. Comments are short, plain and say why, not what.
 - Copy people see is plain English: what happened, how many, since when, and what to do. No unexplained jargon, and
   never a number without its sample size.
-- Tests are few and test whole flows; each one says what real bug or finding it guards.
+- Each test says what real bug or finding it guards; the `tests/test_flow_*.py` files stay few and test whole flows.
 
 ## Pull requests
 

{stackvitals-0.1.2 → stackvitals-0.1.4}/PKG-INFO

@@ -1,7 +1,12 @@
 Metadata-Version: 2.5
 Name: stackvitals
-Version: 0.1.2
+Version: 0.1.4
 Summary: Free, open-source developer suite: CI health, team flow, dependencies, community, and MergeScout for contributors.
+Project-URL: Homepage, https://github.com/stackvitals/stackvitals
+Project-URL: Documentation, https://github.com/stackvitals/stackvitals/tree/main/docs
+Project-URL: Repository, https://github.com/stackvitals/stackvitals
+Project-URL: Issues, https://github.com/stackvitals/stackvitals/issues
+Project-URL: Changelog, https://github.com/stackvitals/stackvitals/blob/main/CHANGELOG.md
 License-Expression: Apache-2.0
 License-File: LICENSE
 License-File: NOTICE
@@ -237,4 +242,4 @@ model families (Claude and Gemini); no person has audited the labels.
 - **Before you rely on it:** [what each rule does](docs/rules.md), [known limitations](docs/limitations.md),
   [what leaves your repo](docs/privacy.md), [threat model](docs/threat-model.md), [enterprise controls](docs/enterprise.md).
 - **More:** [FAQ](docs/faq.md), [how it works](docs/architecture.md), [roadmap](docs/roadmap.md),
-  [contributing](CONTRIBUTING.md), [governance](GOVERNANCE.md), [security](SECURITY.md).
+  [contributing](CONTRIBUTING.md), [code of conduct](CODE_OF_CONDUCT.md), [governance](GOVERNANCE.md), [security](SECURITY.md).

{stackvitals-0.1.2 → stackvitals-0.1.4}/README.md

@@ -195,4 +195,4 @@ model families (Claude and Gemini); no person has audited the labels.
 - **Before you rely on it:** [what each rule does](docs/rules.md), [known limitations](docs/limitations.md),
   [what leaves your repo](docs/privacy.md), [threat model](docs/threat-model.md), [enterprise controls](docs/enterprise.md).
 - **More:** [FAQ](docs/faq.md), [how it works](docs/architecture.md), [roadmap](docs/roadmap.md),
-  [contributing](CONTRIBUTING.md), [governance](GOVERNANCE.md), [security](SECURITY.md).
+  [contributing](CONTRIBUTING.md), [code of conduct](CODE_OF_CONDUCT.md), [governance](GOVERNANCE.md), [security](SECURITY.md).

{stackvitals-0.1.2 → stackvitals-0.1.4}/bench/accuracy/registry.json

@@ -46,15 +46,15 @@
     },
     {
      "date": "2026-10-23",
-     "from": "known flaky passes the verdict check",
+     "from": "a known flake passed the verdict check",
      "why": "13 of 81 held-out safe calls were the change's own failure; matching past flakes' errors didn't separate them",
      "effect": "known flaky still reads 'likely a flake, re-run it', but the verdict check passes only once CI is green"
     },
     {
      "date": "2026-10-23",
-     "from": "known flaky: likely a flake, re-run it",
+     "from": "a known flake read 'likely a flake, re-run it'",
      "why": "in the agent head-to-head a smaller model trusted it on 2 failures the change caused",
-     "effect": "now asks to check the error isn't from the change before re-running; those 2 were then answered right"
+     "effect": "it asks to check the error isn't from the change before re-running; those 2 were then answered right"
     },
     {
      "date": "2026-10-28",
@@ -140,6 +140,34 @@
    "strength": "early observation",
    "strength_why": "2 held-out matches in 150 failures"
   },
+  {
+   "id": "flaky.only_this_pr",
+   "card": "flaky",
+   "version": 1,
+   "rule": "A failure that would read likely flaky, flaked before or maybe flaky, whose flakes in the last 30 days all came from this same pull request (none on the default branch or other pull requests), reads new: a race or order dependence the change added fails now and then and passes on a re-run.",
+   "tuned_on": "none: a public suggestion (2026-10-31) with the failure it describes written as tests",
+   "held_out": "not yet replayed on the labelled pull-request failures",
+   "pass_bar": "none set yet; it only moves a call toward the change and never excuses a failure",
+   "bar_set": "2026-10-31",
+   "result": "untested on labels: the replay needs the held-out reads again",
+   "revisions": [],
+   "strength": "early observation",
+   "strength_why": "not yet measured on labelled failures"
+  },
+  {
+   "id": "flaky.worse_on_pr",
+   "card": "flaky",
+   "version": 1,
+   "rule": "A likely flake that failed 2 or more times on this pull request's runs, where that many failures would come from its default-branch rate (smoothed by one failure and one pass, over 10 or more runs) less than 5% of the time, reads new: the change made a flaky check fail more often.",
+   "tuned_on": "none: a public suggestion (2026-10-31) with the failure it describes written as tests",
+   "held_out": "not yet measured; the plan is regressions seeded into repos of the stackvitals organisation",
+   "pass_bar": "none set yet; it only moves a call toward the change and never excuses a failure",
+   "bar_set": "2026-10-31",
+   "result": "untested on labels",
+   "revisions": [],
+   "strength": "early observation",
+   "strength_why": "not yet measured on seeded or labelled failures"
+  },
   {
    "id": "flaky.pr_details",
    "card": "flaky",

{stackvitals-0.1.2 → stackvitals-0.1.4}/bench/accuracy/summary.py

@@ -312,8 +312,8 @@ def _doc(cs: list[dict], r: dict) -> str:
            f"- Each adjudicator mostly sided with its own family: Claude's {r['cross']['claude_adjudicator_sided_with_claude']} times, "
            f"Gemini's {r['cross']['gemini_adjudicator_sided_with_gemini']} times.",
            "- So each card shows its headline on each labeller's labels as well as the adjudicated ones.",
-           "- A check by six models from three families (OpenAI gpt-5.4-mini and gpt-5-mini, Google gemini-3.8-flash and "
-           "gemini-3.5-flash, Anthropic Claude Sonnet and Haiku), each answering alone the same plain-language questions on "
+           "- A second check: six models from three families (OpenAI gpt-5.4-mini and gpt-5-mini, Google gemini-3.8-flash and "
+           "gemini-3.5-flash, Anthropic Claude Sonnet and Haiku) each answered the same plain-language questions alone, on "
            f"{r['panel6']['items']} labelled items (the CI and reply items drawn first from those the first two labellers "
            "disagreed on). Where a majority formed, it matched the labels on CI causes "
            f"{panel('ci')}, the release behind a bug {panel('incident')}, how releases reach users {panel('deploy')}, "
@@ -325,10 +325,12 @@ def _doc(cs: list[dict], r: dict) -> str:
            "- No person has audited the labels yet.", "",
            "**How sure.** A rule is an *early observation* when its check rests on few cases; its numbers are a direction,",
            "not a settled rate: " + "; ".join(f"`{x['id']}` ({x['strength_why']})" for x in r["registry"]["rules"]
-                                            if x.get("strength") == "early observation") + ". A rule whose bar *failed* is kept "
+                                            if x.get("strength") == "early observation") + ". A rule's *bar* is the accuracy it had to reach before it shipped; for the flaky-test rules it is that at most 5% "
+           "of the failures it calls flaky were really caused by the change (*masking*: a real failure hidden as a flake). "
+           "A rule whose bar *failed* is kept "
            "only where failing costs nothing it promised: " + "; ".join(f"`{x['id']}` ({x['strength_why']})" for x in r["registry"]["rules"]
-                                                           if x.get("strength") == "bar failed") + ". The rest are validated on",
-           "held-out data ([rules.md](rules.md)).", "",
+                                                           if x.get("strength") == "bar failed") + ". The rest are validated: checked against their bar, on held-out data where the rule has one ([rules.md](rules.md) "
+           "says which).", "",
            "**Reproduce a number.** `python bench/accuracy/reproduce.py list` names the command behind every result file;",
            "`reproduce.py check <card>` re-scores it and says whether the numbers match. Scoring reads the evidence each",
            "card was labelled from (the `.work` folders: CI histories, crawl records, logs), which is too large and holds",
@@ -343,7 +345,7 @@ def _doc(cs: list[dict], r: dict) -> str:
             "[registry.json](../bench/accuracy/registry.json).", ""]
     for rule in r["registry"]["rules"]:
         for v in rule.get("revisions") or []:
-            out.append(f"- {v['date']}, `{rule['id']}`: was {v['from']}; {v['why']}; now {v['effect']}.")
+            out.append(f"- {v['date']}, `{rule['id']}`: before, {v['from']}; {v['why']}; after, {v['effect']}.")
     return "\n".join(out) + "\n"
 
 

{stackvitals-0.1.2 → stackvitals-0.1.4}/docs/accuracy.md

@@ -13,12 +13,11 @@ page is built from those cards' result files by `bench/accuracy/summary.py`; the
 - That third reading was Claude's. Gemini, adjudicating a sample of the same disputes, agreed with it on 15 of 40.
 - Each adjudicator mostly sided with its own family: Claude's 33 times, Gemini's 23 times.
 - So each card shows its headline on each labeller's labels as well as the adjudicated ones.
-- A check by six models from three families (OpenAI gpt-5.4-mini and gpt-5-mini, Google gemini-3.8-flash and gemini-3.5-flash, Anthropic Claude Sonnet and Haiku), each answering alone the same plain-language questions on 120 labelled items (the CI and reply items drawn first from those the first two labellers disagreed on). Where a majority formed, it matched the labels on CI causes 21 of the 24 it decided (40 asked), the release behind a bug 11 of the 12 it decided (15 asked), how releases reach users 9 of the 14 it decided (15 asked), but issue replies only 11 of the 24 it decided (30 asked): it called most replies the labels call drive-bys or project answers helpful answers from other users, so the Community card's reply labels are the least settled. On the replay's disputed items it reached no majority on 11 of 20.
+- A second check: six models from three families (OpenAI gpt-5.4-mini and gpt-5-mini, Google gemini-3.8-flash and gemini-3.5-flash, Anthropic Claude Sonnet and Haiku) each answered the same plain-language questions alone, on 120 labelled items (the CI and reply items drawn first from those the first two labellers disagreed on). Where a majority formed, it matched the labels on CI causes 21 of the 24 it decided (40 asked), the release behind a bug 11 of the 12 it decided (15 asked), how releases reach users 9 of the 14 it decided (15 asked), but issue replies only 11 of the 24 it decided (30 asked): it called most replies the labels call drive-bys or project answers helpful answers from other users, so the Community card's reply labels are the least settled. On the replay's disputed items it reached no majority on 11 of 20.
 - No person has audited the labels yet.
 
 **How sure.** A rule is an *early observation* when its check rests on few cases; its numbers are a direction,
-not a settled rate: `flaky.already_failing` (1 of 6 held-out matches with the same error); `flaky.maybe_flaky` (2 held-out matches in 150 failures); `flaky.pr_details` (24 matches in 4 repos, one repo gave most); `dora.incident_link` (15 reports named the release that broke). A rule whose bar *failed* is kept only where failing costs nothing it promised: `flaky.known_flaky` (too few calls to show 5%: the label says "likely", the advice says to check the error first, and the verdict check waits for a green re-run). The rest are validated on
-held-out data ([rules.md](rules.md)).
+not a settled rate: `flaky.already_failing` (1 of 6 held-out matches with the same error); `flaky.maybe_flaky` (2 held-out matches in 150 failures); `flaky.only_this_pr` (not yet measured on labelled failures); `flaky.worse_on_pr` (not yet measured on seeded or labelled failures); `flaky.pr_details` (24 matches in 4 repos, one repo gave most); `dora.incident_link` (15 reports named the release that broke). A rule's *bar* is the accuracy it had to reach before it shipped; for the flaky-test rules it is that at most 5% of the failures it calls flaky were really caused by the change (*masking*: a real failure hidden as a flake). A rule whose bar *failed* is kept only where failing costs nothing it promised: `flaky.known_flaky` (too few calls to show 5%: the label says "likely", the advice says to check the error first, and the verdict check waits for a green re-run). The rest are validated: checked against their bar, on held-out data where the rule has one ([rules.md](rules.md) says which).
 
 **Reproduce a number.** `python bench/accuracy/reproduce.py list` names the command behind every result file;
 `reproduce.py check <card>` re-scores it and says whether the numbers match. Scoring reads the evidence each
@@ -127,22 +126,22 @@ Weak spot: Questions beyond GitHub's 90-day log retention, where kept history ma
 
 Every rule a number rests on, with each revision and why, is in [registry.json](../bench/accuracy/registry.json).
 
-- 2026-10-22, `flaky.event`: was same-code flips in any workflow; all 3 flips that weren't real flakes, and 5 checks of the PR's own text, were pull-request runs of workflows that also run on PR edits or labels; now 9 of 108 events left out (3 wrong, 5 PR-text checks, 1 real timing flake); 99 of 99 kept are real.
-- 2026-10-23, `flaky.event`: was pull-request flips left out in PR-edit workflows; held out, all 17 flips in such workflows were real flakes; now reverted to the earlier rule.
-- 2026-10-22, `flaky.known_flaky`: was any earlier flake; 15 of 34 failures it called safe were caused by the change (44%); now 7 called safe (5 clearly labelled, 0 caused), all one job; the other 29 now cost a look.
-- 2026-10-23, `flaky.known_flaky`: was known flaky passes the verdict check; 13 of 81 held-out safe calls were the change's own failure; matching past flakes' errors didn't separate them; now known flaky still reads 'likely a flake, re-run it', but the verdict check passes only once CI is green.
-- 2026-10-23, `flaky.known_flaky`: was known flaky: likely a flake, re-run it; in the agent head-to-head a smaller model trusted it on 2 failures the change caused; now now asks to check the error isn't from the change before re-running; those 2 were then answered right.
-- 2026-10-28, `flaky.known_flaky`: was 3+ flakes in the window, one in the failing step (history alone); shown as "Known flaky"; held out, 13 of 81 such calls were the change's own failure; a flake's sign in the failing step's log and no changed file named separated them on the tuning data (0 of 31 caused when both held; 8 of 8 clear caused when a changed file was named); now fresh read: 4 of 44 calls kept, 0 caused (0-49%), so the 5% bar is unproven; shown as "Likely flaky" with its evidence, never "safe"; the rest read flaked before, or maybe yours (4 of 5 clear fresh cases caused).
-- 2026-10-22, `flaky.outside_failure`: was failure-section match including 'failed to download and build'; a dependency's own build failing matched; now taken out; 4 matches given up for safety.
-- 2026-10-22, `flaky.outside_failure`: was TEST_FAILED matching any 'FAILED:'; ninja's 'FAILED:' build lines hid an sccache outage; now test-runner forms only.
-- 2026-10-22, `flaky.already_failing`: was the same step alone; 4 of 22 such failures were caused by the change, with a different error in that step; now 12 matched, none caused.
-- 2026-10-23, `flaky.maybe_flaky`: was track record over all 24 signature matches; the product says maybe flaky only for never-flaked failures (a whole-release review); now the track record counts never-flaked matches: 1 of 6 (0 of 4 tuning, 1 of 2 held out).
-- 2026-10-23, `flaky.pr_details`: was error lines mentioning a title, label or description anywhere; a test assertion about chart labels matched; now the words must be about the PR.
-- 2026-10-23, `flaky.pr_details`: was only jobs whose steps read the PR (triggers.metadata_jobs); label checks gated by `if:` and checks reading the PR in a script were missed (2 matches of 24); now any job of a workflow run by PR edits, with the error guard.
-- 2026-10-23, `flaky.pr_details`: was "checkbox", "template" or "PR" alone; any failing step; a whole-release review: a template rendering error in a CI workflow run on labels matched; now those words need the PR's wording beside them, and a failing test rules it out; still 24 of 24 matched.
-- 2026-10-21, `dora.deploy_source`: was display name checked against the deny list; a file named deploy.yml titled 'Check and Publish' hit the deny word 'check'; now a file named only deploy, release or publish ships whatever its display name; 22 to 23 of 25.
-- 2026-10-22, `dora.fix_chain`: was every revert counted as a failed deployment; 11 of 18 undid a change that never shipped; now never-shipped reverts are no failed deployment.
-- 2026-10-23, `community.regular_responders`: was answers and first reviews only; triage acts mark people acting for the project; on the labelled comments the rule missed, they found 8 project answers among 11; now held out: 4 more project answers (47% to 57% weighted); on Claude's labels 45% to 53%, on Gemini's 32% to 38%.
-- 2026-10-22, `community.first_response_km`: was closed-unanswered items treated as still waiting; they stopped being at risk when they closed; now censored at closing.
-- 2026-10-24, `uncertainty.digest`: was weekly checks only; in a slowdown's second week the weekly check's baseline holds the first slow week, so 10x slowdowns were caught in 15% of scans; now on the same replay, second-week catches of 10x slowdowns 15% to 35%, first-week 31% to 25%, false alarms 7.4% to 7.5%; CUSUM charts tried and dropped (no gain).
-- 2026-10-23, `ai.detection`: was AI trailers in the last 5 commits, labels matched exactly, agent account or branch; 5 of 23 missed PRs named the tool in their description; label spellings and Jules task links missed in the tune half; now recall 75.0% to 78.8% weighted (63.9% to 66.3% held out); precision 185 of 187 to 191 of 194.
+- 2026-10-22, `flaky.event`: before, same-code flips in any workflow; all 3 flips that weren't real flakes, and 5 checks of the PR's own text, were pull-request runs of workflows that also run on PR edits or labels; after, 9 of 108 events left out (3 wrong, 5 PR-text checks, 1 real timing flake); 99 of 99 kept are real.
+- 2026-10-23, `flaky.event`: before, pull-request flips left out in PR-edit workflows; held out, all 17 flips in such workflows were real flakes; after, reverted to the earlier rule.
+- 2026-10-22, `flaky.known_flaky`: before, any earlier flake; 15 of 34 failures it called safe were caused by the change (44%); after, 7 called safe (5 clearly labelled, 0 caused), all one job; the other 29 now cost a look.
+- 2026-10-23, `flaky.known_flaky`: before, a known flake passed the verdict check; 13 of 81 held-out safe calls were the change's own failure; matching past flakes' errors didn't separate them; after, known flaky still reads 'likely a flake, re-run it', but the verdict check passes only once CI is green.
+- 2026-10-23, `flaky.known_flaky`: before, a known flake read 'likely a flake, re-run it'; in the agent head-to-head a smaller model trusted it on 2 failures the change caused; after, it asks to check the error isn't from the change before re-running; those 2 were then answered right.
+- 2026-10-28, `flaky.known_flaky`: before, 3+ flakes in the window, one in the failing step (history alone); shown as "Known flaky"; held out, 13 of 81 such calls were the change's own failure; a flake's sign in the failing step's log and no changed file named separated them on the tuning data (0 of 31 caused when both held; 8 of 8 clear caused when a changed file was named); after, fresh read: 4 of 44 calls kept, 0 caused (0-49%), so the 5% bar is unproven; shown as "Likely flaky" with its evidence, never "safe"; the rest read flaked before, or maybe yours (4 of 5 clear fresh cases caused).
+- 2026-10-22, `flaky.outside_failure`: before, failure-section match including 'failed to download and build'; a dependency's own build failing matched; after, taken out; 4 matches given up for safety.
+- 2026-10-22, `flaky.outside_failure`: before, TEST_FAILED matching any 'FAILED:'; ninja's 'FAILED:' build lines hid an sccache outage; after, test-runner forms only.
+- 2026-10-22, `flaky.already_failing`: before, the same step alone; 4 of 22 such failures were caused by the change, with a different error in that step; after, 12 matched, none caused.
+- 2026-10-23, `flaky.maybe_flaky`: before, track record over all 24 signature matches; the product says maybe flaky only for never-flaked failures (a whole-release review); after, the track record counts never-flaked matches: 1 of 6 (0 of 4 tuning, 1 of 2 held out).
+- 2026-10-23, `flaky.pr_details`: before, error lines mentioning a title, label or description anywhere; a test assertion about chart labels matched; after, the words must be about the PR.
+- 2026-10-23, `flaky.pr_details`: before, only jobs whose steps read the PR (triggers.metadata_jobs); label checks gated by `if:` and checks reading the PR in a script were missed (2 matches of 24); after, any job of a workflow run by PR edits, with the error guard.
+- 2026-10-23, `flaky.pr_details`: before, "checkbox", "template" or "PR" alone; any failing step; a whole-release review: a template rendering error in a CI workflow run on labels matched; after, those words need the PR's wording beside them, and a failing test rules it out; still 24 of 24 matched.
+- 2026-10-21, `dora.deploy_source`: before, display name checked against the deny list; a file named deploy.yml titled 'Check and Publish' hit the deny word 'check'; after, a file named only deploy, release or publish ships whatever its display name; 22 to 23 of 25.
+- 2026-10-22, `dora.fix_chain`: before, every revert counted as a failed deployment; 11 of 18 undid a change that never shipped; after, never-shipped reverts are no failed deployment.
+- 2026-10-23, `community.regular_responders`: before, answers and first reviews only; triage acts mark people acting for the project; on the labelled comments the rule missed, they found 8 project answers among 11; after, held out: 4 more project answers (47% to 57% weighted); on Claude's labels 45% to 53%, on Gemini's 32% to 38%.
+- 2026-10-22, `community.first_response_km`: before, closed-unanswered items treated as still waiting; they stopped being at risk when they closed; after, censored at closing.
+- 2026-10-24, `uncertainty.digest`: before, weekly checks only; in a slowdown's second week the weekly check's baseline holds the first slow week, so 10x slowdowns were caught in 15% of scans; after, on the same replay, second-week catches of 10x slowdowns 15% to 35%, first-week 31% to 25%, false alarms 7.4% to 7.5%; CUSUM charts tried and dropped (no gain).
+- 2026-10-23, `ai.detection`: before, AI trailers in the last 5 commits, labels matched exactly, agent account or branch; 5 of 23 missed PRs named the tool in their description; label spellings and Jules task links missed in the tune half; after, recall 75.0% to 78.8% weighted (63.9% to 66.3% held out); precision 185 of 187 to 191 of 194.

{stackvitals-0.1.2 → stackvitals-0.1.4}/docs/app.md

@@ -17,12 +17,11 @@ explorer, which fetches DuckDB once) and has no tracking. The bundled libraries
 | `index.html?pages=https://owner.github.io/name/` | Another repo's Pages site |
 | `index.html?welcome` | The Welcome screen |
 
-Links from the earlier app still work: `#/home` opens Overview and `#/integrations` opens Connections.
 
 ## Layout
 
 The sidebar groups the pages: **Health** (Overview, Insights, CI Health, Pull Requests, Delivery, Community,
-Dependencies), **Organisation** (Investment, Portal, Explore), **Team** (Activity, Settings) and **Install** (Setup,
+Dependencies), **Organisation** (Investment, Portal, Explore), **Team** (Activity, Data health, Settings) and **Install** (Setup,
 Connections, Agents, Help, About). A badge shows what waits on a page, for example flaky tests or newcomers waiting. A
 page for a module that isn't set up is dimmed. On a phone the sidebar becomes a tab bar (Overview, Insights, CI, PRs)
 with the rest under **More**.
@@ -58,7 +57,7 @@ Once GitHub is connected, setup takes a few clicks; connecting takes one token,
 **Setup** picks a repo, checks what it has and suggests a plan (modules ticked from what it finds) that you can change.
 **Set it up** then commits the workflow (a pull request when the branch is protected), starts the first run and shows it
 live, waits for the data branch and turns on Pages for public repos. Each step is saved, so a reload picks up where it
-stopped. Without a token you get the file ready to add on GitHub, the YAML to copy, or the CLI command, and the app
+stopped. Without a token you get the file ready to add on GitHub, the YAML to copy, or the one CLI command (`stackvitals init owner/repo`), and the app
 checks for the first run at a pace that stays inside GitHub's limit for visitors.
 
 ## Pages

{stackvitals-0.1.2 → stackvitals-0.1.4}/docs/architecture.md

@@ -17,8 +17,10 @@ way back: settings and decisions made in the app.
 ### 1. What starts a run
 
 A run starts when any of these happens: a CI run finishes (`workflow_run`), the 3-hour schedule comes round, a deploy or
-incident is sent from another tool (`stackvitals record`), someone makes a request in the app (`workflow_dispatch`),
-someone comments `/stackvitals` on an issue or pull request, or the workflow or settings file changes (`push`). Each
+incident is sent from another tool (`stackvitals record`, which sends a `repository_dispatch`), someone makes a request
+in the app (an issue it opens, or `workflow_dispatch`), someone comments `/stackvitals` on an issue or pull request
+(`issue_comment`), a pull request changes a lockfile (`pull_request`, for the dependency check), or the workflow or
+settings file changes (`push`). Each
 start is the same job; what it reads depends on what started it.
 
 ### 2. Collect
@@ -33,9 +35,10 @@ Copilot usage, Slack, Teams and Discord ([connectors.md](connectors.md)).
 
 ### 3. Analyse
 
-Six modules read the same collected data in one pass: CI Health (flaky tests and the verdict on each failing pull
+The modules read the same collected data in one pass: CI Health (flaky tests and the verdict on each failing pull
 request), Team Flow (who has to act next), Delivery and DORA (deploys, lead time and failures), Dependencies (vulnerable
-and risky packages), Community (newcomers and first answers) and Portal (owners and scorecards). Insights then puts
+and risky packages), Community (newcomers and first answers) and Portal (owners and scorecards; it runs from the org's own portal repo
+with its own workflow, not in each repo's run). Insights then puts
 every module's findings in one list, ranked by the hours at stake.
 
 Every verdict stands on two things: the **rules registry**, where each rule has an accuracy card measured on public repos
@@ -138,7 +141,7 @@ in `deploy/crawler/`. It publishes aggregates only. Your job reads them; it neve
 | `src/stackvitals/deps` | Dependency Steward |
 | `src/stackvitals/community` | Community health |
 | `src/stackvitals/portal` | Portal: catalog, owners, scorecards, campaigns, golden paths, the org view |
-| `src/stackvitals/connectors` | Jira, Linear, PagerDuty, incident.io, Copilot, Slack, Discord, Discourse |
+| `src/stackvitals/connectors` | Jira, Linear, PagerDuty, incident.io, SonarQube, Copilot and AI-spend keys, Slack, Discord, Discourse (Teams and the other chat alerts are in `core/chat.py`) |
 | `src/stackvitals/web` | the app and the site |
 | `src/stackvitals/mcp_server.py` | the MCP server |
 | `src/mergescout` | Contribute (MergeScout) |