stackvitals 0.1.2__tar.gz → 0.1.3__tar.gz

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

@@ -1,5 +1,17 @@
 # Changelog
 
+## 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.3/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.3}/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.3}/PKG-INFO

@@ -1,7 +1,12 @@
 Metadata-Version: 2.5
 Name: stackvitals
-Version: 0.1.2
+Version: 0.1.3
 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.3}/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.3}/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",

{stackvitals-0.1.2 → stackvitals-0.1.3}/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.3}/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.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.3}/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.3}/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) |

{stackvitals-0.1.2 → stackvitals-0.1.3}/docs/connectors.md

@@ -117,8 +117,8 @@ goes through a server of ours, and the keys are only used to read unless you tur
   shows it, an email). With `[identity] aliases` naming those people's GitHub logins, Delivery counts issues done
   per team, and Slack and Discord count a reply from an aliased team member as the team's, so nobody is listed twice.
   Without an alias, an assignee whose email name is a GitHub login of this repo (`bo@acme.com` for `bo`) counts as
-  that login; one whose email or name only reads like a login (`kaushik.yadav@` or "Kaushik Yadav" for
-  `kaushik-yadav`) is not counted, but the Issues view offers the alias line to paste. A public repo keeps no assignee.
+  that login; one whose email or name only reads like a login (`jane.doe@` or "Jane Doe" for
+  `jdoe`) is not counted, but the Issues view offers the alias line to paste. A public repo keeps no assignee.
 - Only connectors whose key is in the workflow count: remove a key, and its issues and incidents stop counting (what
   was pulled stays on the branch and counts again if the key comes back).
 - Like the rest of the history, connector day files are kept 400 days (Copilot reports two years) and count toward
@@ -331,7 +331,6 @@ request's pipeline failed it leaves one note (edited on later pipelines, and to
 which failures are known flakes or also fail on the default branch. If the push to `stackvitals-data` is refused (a
 protected branch, a push rule, or a token without `write_repository`), the job fails and says so. GitLab has no "after
 the pipeline" trigger, so the job reads its own pipeline while it runs; there is no verdict check to block a merge. It
-is tested against a stand-in GitLab API, not a live project yet. The include works once the `v0` tag is made at launch;
-until then use `main` in its URL and set the `STACKVITALS_REF` variable to `main`.
+is tested against a stand-in GitLab API, not a live project yet.
 
 The merge request, deployment and incident records above come next, in the same job.

{stackvitals-0.1.2 → stackvitals-0.1.3}/docs/coverage.md

@@ -1,6 +1,7 @@
 # Coverage and peer groups
 
-When StackVitals compares your repo with "similar public repos", the peers come from the MergeScout crawler, which reads public GitHub repos daily on GitHub Actions. This page says what it reads, what it misses, and how each peer group is formed.
+When StackVitals compares your repo with "similar public repos", the peers come from the project's crawler (built for MergeScout, the Contribute module, and now feeding every
+benchmark), which reads public GitHub repos daily on GitHub Actions. This page says what it reads, what it misses, and how each peer group is formed.
 
 ## What the crawl reads
 

{stackvitals-0.1.2 → stackvitals-0.1.3}/docs/dora-guide.md

@@ -8,7 +8,8 @@ one can't tell you and how each is gamed, so a team can read them honestly.
 
 DORA groups its [five software delivery metrics](https://dora.dev/guides/dora-metrics/) in two: throughput (deployment
 frequency, change lead time, failed deployment recovery time) and instability (change fail rate, deployment rework
-rate). StackVitals counts the first four with Apache DevLake's definitions (an incident blames the last production
+rate). StackVitals counts deployment frequency, change lead time, failed deployment recovery time and change fail rate with
+Apache DevLake's definitions (an incident blames the last production
 deployment before it), and shows beside the change fail rate a second one where a revert blames the deployment that
 shipped what it undid; rework rate is the share of deployments that shipped an unplanned fix. The tiers (elite,
 high, medium, low) come from DevLake's 2023 table, which predates rework rate, so rework rate has no tier.
@@ -48,4 +49,5 @@ the delivery, and the number stops meaning anything (Goodhart's law).
 ## Further reading
 
 - DORA's own guidance on the metrics and their misuse: <https://dora.dev/guides/dora-metrics-four-keys/>
-- LinearB's definitions of the six cycle-time phases: <https://linearb.helpdocs.io/article/1s38stsugw-glossary-metrics>
+- LinearB's definitions of the four cycle-time phases (coding, pickup, review, deploy; review is shown split into its
+  approve and merge times): <https://linearb.helpdocs.io/article/1s38stsugw-glossary-metrics>

{stackvitals-0.1.2 → stackvitals-0.1.3}/docs/faq.md

@@ -67,7 +67,7 @@ command line takes the same two variables when you run it against your server.
 
 ## Is there a login, with roles for who sees what?
 
-Yes, and it is GitHub's own. The app signs in with GitHub and reads each repo's data branch with your access, so a
+Yes, and it is GitHub's own. The app uses your GitHub token (or GitHub sign-in, where the site has a sign-in relay) and reads each repo's data branch with your access, so a
 person sees exactly the repos GitHub already lets them read, and an org's roles (members, outside collaborators, teams)
 apply unchanged; Portal's org view shows only the repos the viewer can open. Nothing is copied to a server of ours to
 guard, so there is no second user list to keep in step. What you don't get is a separate admin screen for roles: you

{stackvitals-0.1.2 → stackvitals-0.1.3}/docs/guides/maintainer.md

@@ -5,7 +5,7 @@ is free on public repos and needs only the built-in token.
 
 ## Set it up
 
-[Quickstart](../quickstart.md): one workflow file, then GitHub Pages from the `stackvitals-data` branch. Your
+[Quickstart](../quickstart.md): `stackvitals init owner/repo` adds the workflow file, runs it once and turns on GitHub Pages from the `stackvitals-data` branch. Your
 dashboard is public like your repo. Your code stays in GitHub; the dependency check sends package names to deps.dev
 and the registries unless you set `[deps] outside_lookups = false` ([privacy](../privacy.md)).
 

{stackvitals-0.1.2 → stackvitals-0.1.3}/docs/guides/manager.md

@@ -8,13 +8,13 @@ You want to know where your team's time goes and whether changes help, without r
    90 days of CI and a year of pull requests on the first run, so you start with history, not an empty page.
 2. **Open Insights** in the app: one list of what to fix first across CI, reviews and delivery, ranked by hours at
    stake ([modules](../modules.md#insights-what-to-fix-first)). Start at the top.
-3. **Read Delivery** for cycle time in LinearB's phases and DORA's five metrics. Before you share a DORA number,
+3. **Read Delivery** for cycle time in LinearB's phases (coding, pickup, review, deploy) and DORA's five metrics (the industry's standard delivery measures: how often you deploy, how long a change takes to ship, how often a change fails, and how fast you recover). Before you share a DORA number,
    read [the DORA guide](../dora-guide.md): what each number can't tell, how it gets gamed, and why it is never for
    individual reviews.
 
 ## Every week
 
-- The **weekly digest** (Monday, one comment on a pinned issue; add your chat under `[digest] channels`) says what
+- The **weekly digest** (Monday, one comment on a pinned issue; to post it to chat too, set the `webhook` input, then `channels = ["issue", "webhook"]` under `[digest]`) says what
   changed. It reports a change only when it stands out from how much your repo's weeks usually swing, so false alarms
   are rare, but a quiet digest means nothing stood out, not that nothing moved: on small repos even large slowdowns
   can go unflagged ([modules](../modules.md#decide-on-github-hear-back-every-week)).

{stackvitals-0.1.2 → stackvitals-0.1.3}/docs/guides/platform.md

@@ -6,11 +6,11 @@ and a security review you can sign off.
 ## Roll it out
 
 1. **Portal first.** Create a private repo (for example `portal`) and save the workflow from
-   `stackvitals portal init` in it (`stackvitals portal check my-org` first says what your token can read). With the built-in token it reads public repos; for private ones, an org
+   `stackvitals portal init` in it (`stackvitals portal check my-org` first says what your token can read (it uses your `gh auth login` or `GITHUB_TOKEN`)). With the built-in token it reads public repos; for private ones, an org
    owner creates a read-only org App (`stackvitals portal app-link my-org` opens GitHub's form filled in)
    ([modules](../modules.md#portal)).
-2. **The suite per repo.** Each team adds the workflow ([quickstart](../quickstart.md)); `uvx stackvitals ci init
-   OWNER/REPO` writes it with that repo's CI workflows named. Private repos set `pages: artifact` (each run that
+2. **The suite per repo.** Each team runs `stackvitals init OWNER/REPO` ([quickstart](../quickstart.md)), which
+   commits the workflow with that repo's CI workflows named and follows the first run. Private repos set `pages: artifact` (each run that
    changed the app uploads it as a download kept 7 days) or open the app with `stackvitals ui OWNER/REPO`.
 3. **Settings as code.** `.github/stackvitals.toml` per repo; every setting, its default and the permission it needs
    are in [settings.md](../settings.md).

{stackvitals-0.1.2 → stackvitals-0.1.3}/docs/install.md

@@ -1,6 +1,27 @@
 # Install
 
-StackVitals is a GitHub Action, `uses: stackvitals/stackvitals@v0`, run by one workflow file in your repo. The file below is exactly what `stackvitals ci init owner/repo` prints (that command also fills in your CI workflows' names) and what the app's Setup page commits for you. Save it as `.github/workflows/stackvitals.yml`; committing it starts the first run. No settings file is needed: a missing `.github/stackvitals.toml` means the defaults ([settings.md](settings.md)).
+StackVitals has two parts: a GitHub Action, `uses: stackvitals/stackvitals@v0`, that runs in your repo, and the `stackvitals` command on your machine, which sets the Action up, opens a private repo's dashboard and runs the MCP server for AI agents. The Action needs nothing installed; the command is one `pip install`.
+
+## Get the command
+
+```sh
+pip install stackvitals      # Python 3.11 or newer
+gh auth login                # once; or set GITHUB_TOKEN
+```
+
+Or run any command without installing, with [uv](https://docs.astral.sh/uv/): `uvx stackvitals init owner/repo`. Upgrade with `pip install -U stackvitals`. `stackvitals sql` needs the SQL extra: `pip install "stackvitals[sql]"`. The same package holds the CLI, `stackvitals ui` (a dashboard on your machine) and the MCP server (`stackvitals serve`).
+
+## Set up a repo
+
+```sh
+stackvitals init owner/repo
+```
+
+`init` commits the workflow file below (or opens a pull request when the branch is protected or a different `stackvitals.yml` is there), follows the first run and turns on GitHub Pages for a public repo. A private repo keeps Pages off, since a Pages site is public on most plans: open its dashboard with `stackvitals ui owner/repo`. The app's Setup page does the same without a terminal. More: [quickstart.md](quickstart.md).
+
+`stackvitals/stackvitals@v0` follows the latest release; to pin an exact one, use its version tag (`stackvitals/stackvitals@vX.Y.Z`, listed under [releases](https://github.com/stackvitals/stackvitals/releases)).
+
+The rest of this page is the reference for doing it by hand. The file below is exactly what `stackvitals ci init owner/repo` prints (that command also fills in your CI workflows' names) and what `init` and the app's Setup page commit for you. Save it as `.github/workflows/stackvitals.yml`; committing it starts the first run. No settings file is needed: a missing `.github/stackvitals.toml` means the defaults ([settings.md](settings.md)).
 
 ## Modules
 

{stackvitals-0.1.2 → stackvitals-0.1.3}/docs/limitations.md

@@ -133,8 +133,8 @@ verdict check, `issues: write` for flaky-test issues.
   a docs index, with GitHub's own sign-in and repository roles. It doesn't replace an internal developer portal with
   plugins, live service data from clouds or its own access control (Backstage, Port, Cortex, OpsLevel); it exports
   to Backstage instead.
-- Golden paths open a pull request in a repo the requester can already write to; they never create repos or run
-  arbitrary scripts. Required checks post a check run; a branch rule must still name it.
+- Golden paths open a pull request in a repo the requester can already write to, or create a repo from a template
+  when the org App may create repos; they never run arbitrary scripts. Required checks post a check run; a branch rule must still name it.
 - The built-in token reads public repos only; private repos need an org-owned read-only App. A public portal repo
   leaves private repos out.
 - The org view adds up and takes medians of what each repo published; repos that never ran a module are left out of
@@ -153,7 +153,7 @@ verdict check, `issues: write` for flaky-test issues.
 - **Copilot:** needs an org App with "Organization Copilot metrics: read"; the workflow token can't have it. Each day
   arrives two days late.
 - **Untested live:** comment commands' access check and uploads from other CI systems are covered by tests only.
-- **GitLab:** CI only (flaky jobs, pages, merge request notes; no verdict check); merge requests, deploys and incidents aren't read yet. The GitLab job is tested against a stand-in API, not a live project.
+- **GitLab:** CI only (flaky jobs, pages, merge request notes; no verdict check); the GitLab job doesn't read merge requests, deploys or incidents yet (the command line reads merge requests and deployments: `stackvitals delivery group/project --gitlab`). The GitLab job is tested against a stand-in API, not a live project.
 
 ## The app
 
@@ -195,5 +195,5 @@ What happens when something goes wrong mid-run. Each line is held by a test in `
 | A JSON test report stopped early | Read and marked as cut short | `test_a_json_report_that_stopped_early_says_so` |
 | A pull request's own files try to fool or break the dependency check | Odd file names can't inject workflow commands, a renamed or off-registry package borrows no verdict, an unreadable lockfile is skipped | `test_the_pr_check_cannot_be_fooled_or_broken_by_the_prs_own_files` |
 
-**Not tested yet:** Bors and other merge bots outside GitHub's merge queue, monorepo task runners (Nx, Turborepo,
-Bazel) that skip unchanged tests, and GitHub Enterprise Server.
+**Not tested yet:** Bors and other merge bots outside GitHub's merge queue, and monorepo task runners (Nx, Turborepo,
+Bazel) that skip unchanged tests. GitHub Enterprise Server is tested against a stand-in server only, not a live one.

{stackvitals-0.1.2 → stackvitals-0.1.3}/docs/methods.md

@@ -28,7 +28,7 @@ half, the upper end reads "or more". Under 10 items, the page says "too few".
 
 Fewer than 5 items on either side is not a test: it says "too few to tell" and doesn't count against the others.
 
-**Calibration.** Work arrives in batches, so events in a week are not independent. Each number is also tested for each
+**Calibration.** In short: a repo whose numbers usually swing a lot needs a bigger change before it is called a change. Work arrives in batches, so events in a week are not independent. Each number is also tested for each
 of the repo's past 8 weeks, and the spread of those results (mean squared z, each capped at 16) widens this week's
 test. The spread is blended with a typical swing worth 4 weeks:
 - 1.5 for review times, set on half of 20 public repos and checked on the other half;
@@ -81,7 +81,7 @@ Each card's labelled sample is labelled twice, by two different model families,
 1. **Claude**, which made the first labels.
 2. **Gemini (Flash-Lite)**, from the same codebook and evidence.
 
-Disagreements are settled by a third reading with both answers and the evidence. Cards publish both labellers'
+Disagreements are settled by a third reading (by Claude) with both answers and the evidence. Cards publish both labellers'
 agreement (share and Cohen's kappa) and every changed label. No person has audited the labels yet.
 
 Only links and labels are published, never log text.