Skip to content

fix: align landing page copy to output/outcome/impact distinction#4

Merged
simonheimlicher merged 4 commits intomainfrom
fix/copy-output-outcome-alignment
Mar 3, 2026
Merged

fix: align landing page copy to output/outcome/impact distinction#4
simonheimlicher merged 4 commits intomainfrom
fix/copy-output-outcome-alignment

Conversation

@simonheimlicher
Copy link
Copy Markdown
Contributor

Summary

  • Resolve output/outcome conflation across the landing page, applying canonical terminology from the feedback doc
  • Replace "prove" with "show"/"satisfy", "claims" with "assertions", fix labels that implied the Spec Tree tracks customer behavior
  • Distinguish outcome specs from enabler specs instead of saying every spec begins with an outcome hypothesis
  • Replace status-rollup example (output masquerading as outcome) with billing domain example
  • Add missing eslint-plugin-react-hooks dependency that was breaking spx validation

Changes by file

File Issue Fix
HeroSection.tsx "prove what holds", "claims the code must prove", Leaves label implies tree shows customer behavior "show what holds", "assertions the code must satisfy", output-level description
WhyOutcomesSection.tsx "Every spec begins with an outcome hypothesis" (false for enablers) "Outcome specs begin with a hypothesis... Enabler specs begin with what they enable."
story-data.tsx "outcomes express testable hypotheses" heading, "every outcome has evidence" "outcomes state hypotheses about customer change", separate assertion evidence from outcome validation
WhatChangesSection.tsx "Goals have evidence" (implies tree evidences outcomes) "Assertions have evidence"
NodeAnatomySection.tsx Status-rollup example (output as outcome) Billing domain example with clear output/outcome/impact
package.json Missing eslint-plugin-react-hooks Added as devDependency

Terminology applied (from FEEDBACK-landing-and-spec-tree.md)

  • Output layer: assertions + tests + lock evidence (locally testable)
  • Outcome layer: customer behavior change (requires real users)
  • Impact layer: business metric movement (increase/sustain revenue, reduce/avoid costs)
  • Use "validate" and "satisfy", never "prove"
  • Lock state = assertion evidence, not outcome evidence

Test plan

  • pnpm build passes
  • spx validation all passes
  • Visual review of landing page via pnpm dev
  • Trigger /gemini review after PR is open

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
@vercel
Copy link
Copy Markdown

vercel bot commented Mar 3, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
outcomeengineering Ready Ready Preview, Comment Mar 3, 2026 0:07am

Request Review

@simonheimlicher
Copy link
Copy Markdown
Contributor Author

/gemini review

@gemini-code-assist
Copy link
Copy Markdown

Summary of Changes

Hello, 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

  • Terminology Alignment: The landing page copy has been updated to consistently use the canonical terminology for output, outcome, and impact, resolving previous conflation.
  • Refined Language: Phrases like 'prove what holds' and 'claims the code must prove' have been replaced with 'show what holds' and 'assertions the code must satisfy' for improved clarity.
  • Spec Distinction: The content now clearly distinguishes between outcome specs and enabler specs, clarifying their respective starting points and purposes.
  • Example Update: The example in the Node Anatomy section has been changed from a status-rollup (which previously blurred output and outcome) to a billing domain example that distinctly illustrates output, outcome, and impact.
  • Dependency Fix: The missing eslint-plugin-react-hooks dependency, which caused spx validation to break, has been added.
Changelog
  • package.json
    • Added eslint-plugin-react-hooks as a development dependency.
  • pnpm-lock.yaml
    • Updated dependency resolutions and added new package entries to reflect the new eslint-plugin-react-hooks dependency and its transitive dependencies.
  • src/components/HeroSection.tsx
    • Updated copy to align with output/outcome/impact distinction and revised descriptions for 'Branches' and 'Leaves'.
  • src/components/NodeAnatomySection.tsx
    • Replaced the status-rollup example with a billing domain example for clarity on output/outcome/impact.
  • src/components/WhatChangesSection.tsx
    • Changed the heading from 'Goals have evidence' to 'Assertions have evidence'.
  • src/components/WhyOutcomesSection.tsx
    • Clarified the definitions and distinctions between outcome specs, enabler specs, output, outcome, and impact.
  • src/lib/story-data.tsx
    • Updated descriptions for product nodes, decision records, enablers, and outcomes to refine terminology and clarify concepts.
Activity
  • No human activity has been recorded on this pull request yet.
Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.",
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

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.

Suggested change
"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.",

Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +64 to +66
eslint-plugin-react-hooks:
specifier: ^7.0.1
version: 7.0.1(eslint@9.39.3(jiti@2.6.1))
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

security-critical critical

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.

Comment on lines +4 to +13
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))`;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

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.
@simonheimlicher simonheimlicher merged commit afb6a46 into main Mar 3, 2026
2 of 3 checks passed
@simonheimlicher simonheimlicher deleted the fix/copy-output-outcome-alignment branch March 3, 2026 12:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant