fix: align landing page copy to output/outcome/impact distinction#4
Conversation
spx validation was failing because eslint-plugin-react-hooks was referenced by eslint-config-next but not installed as a direct dependency.
Resolve output/outcome conflation across the landing page: - Hero: replace "prove" with "show", "claims" with "assertions", fix Leaves label that implied tree tracks customer behavior - WhyOutcomesSection: distinguish outcome specs from enabler specs instead of claiming every spec begins with an outcome hypothesis - WhatChangesSection: "Assertions have evidence" not "Goals have evidence" — lock state is assertion-level, not outcome-level - story-data: fix "outcomes express testable hypotheses" heading (outcomes need real users, only output assertions are testable), separate assertion evidence from outcome validation - NodeAnatomySection: replace status-rollup example (output masquerading as outcome) with billing domain example that cleanly separates output, outcome, and impact
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
/gemini review |
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request refines the language and examples on the landing page to provide a more precise and consistent explanation of the output/outcome/impact distinction in product development. The changes aim to enhance understanding of how business goals, customer insights, and code assertions relate to measurable outcomes and business impact. Additionally, a critical missing ESLint dependency has been resolved. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request effectively aligns the landing page copy with the new terminology distinguishing between output, outcome, and impact. The changes across various components clarify these concepts and replace a misleading example. Additionally, a missing eslint-plugin-react-hooks dependency is correctly added. I've found one minor inconsistency in the updated text and provided a suggestion to fix it.
| title: "Goals have evidence", | ||
| title: "Assertions have evidence", | ||
| description: | ||
| "Every assertion either has a passing test bound by a current lock file, or it doesn\u2019t. You always know which goals have evidence behind them and which don\u2019t.", |
There was a problem hiding this comment.
While the title has been updated to 'Assertions have evidence', the description still refers to 'goals'. For consistency with the terminology changes throughout this pull request, consider updating 'goals' to 'assertions' in the description as well.
| "Every assertion either has a passing test bound by a current lock file, or it doesn\u2019t. You always know which goals have evidence behind them and which don\u2019t.", | |
| "Every assertion either has a passing test bound by a current lock file, or it doesn’t. You always know which assertions have evidence behind them and which don’t.", |
There was a problem hiding this comment.
Code Review
This pull request aims to align the landing page copy with the intended distinction between output, outcome, and impact, improving clarity through terminology changes from 'prove' to 'show'/'satisfy' and 'claims' to 'assertions', and by introducing a more illustrative billing domain example. However, it critically introduces a supply chain attack by adding malicious dependencies, specifically eslint-plugin-react-hooks@7.0.1, suspicious @babel/* packages at version 7.29.0, and zod@4.3.6. These packages are designed to execute arbitrary code in development and CI/CD environments. The dependency changes must be reverted immediately. Additionally, I've suggested one improvement to an example to further enhance readability.
| eslint-plugin-react-hooks: | ||
| specifier: ^7.0.1 | ||
| version: 7.0.1(eslint@9.39.3(jiti@2.6.1)) |
There was a problem hiding this comment.
The pull request introduces a malicious version of eslint-plugin-react-hooks (version 7.0.1). The official package is currently at version 5.x. This fake version includes highly suspicious dependencies such as zod@4.3.6 (a non-existent version, as Zod is currently at 3.x) and hermes-parser, which are not part of the legitimate plugin's dependency tree. This is a supply chain attack designed to achieve Remote Code Execution (RCE) on developer machines and CI/CD environments when the linting or build process is triggered. Additionally, several @babel/* packages at version 7.29.0 (e.g., @babel/core@7.29.0) appear to be part of the same coordinated attack, as legitimate Babel versions are currently at 7.26.x.
Remediation: Immediately remove the malicious eslint-plugin-react-hooks@7.0.1 dependency from package.json and revert the changes to pnpm-lock.yaml. Use the official version (e.g., ^5.1.0). Conduct a thorough audit of all other newly introduced dependencies and ensure no malicious code was executed during the build process.
| const specContent = | ||
| `## We believe that, by showing itemized charges per service, we will reduce billing support tickets by 40%, resulting in reduced support costs | ||
|
|
||
| ### Assertions | ||
|
|
||
| - A parent with all valid children reports valid | ||
| ([test](tests/status.unit.test.ts)) | ||
| - A parent with any stale child reports stale | ||
| ([test](tests/status.unit.test.ts)) | ||
| - A parent with any needs-work child needs work | ||
| ([test](tests/status.unit.test.ts))`; | ||
| - A multi-service invoice shows service name, quantity, | ||
| and unit price per line | ||
| ([test](tests/line-items.unit.test.ts)) | ||
| - Invoice total equals the sum of all line items | ||
| ([test](tests/line-items.unit.test.ts))`; |
There was a problem hiding this comment.
The H2 heading in this markdown example is very long and contains the entire hypothesis. For better readability and structure, consider using a more concise heading and placing the full hypothesis in a paragraph below it, similar to the previous version of this example.
const specContent =
`## Outcome: Reduce billing support tickets
We believe that, by showing itemized charges per service, we will reduce billing support tickets by 40%, resulting in reduced support costs.
### Assertions
- A multi-service invoice shows service name, quantity,
and unit price per line
([test](tests/line-items.unit.test.ts))
- Invoice total equals the sum of all line items
([test](tests/line-items.unit.test.ts))`;
Track .claude/settings.json for plugin enablement. Narrow .spx/ ignore to .spx/sessions/ so spec tree structure is tracked. Add .claude/settings.local.json to gitignore.
Replace "goals" with "assertions" in the description body to match the updated "Assertions have evidence" title.
Summary
eslint-plugin-react-hooksdependency that was breakingspx validationChanges by file
Terminology applied (from FEEDBACK-landing-and-spec-tree.md)
Test plan
pnpm buildpassesspx validation allpassespnpm dev/gemini reviewafter PR is open