@hassangameryt/freeflow 0.3.0 → 0.5.0

package/skills/write-spec/references/spec-shapes.md

@@ -1,69 +1,128 @@
 # Spec Shapes
 
-Use this when the requested artifact type is unclear, the spec is strict-workflow or future-agent-facing, or a concise shape would prevent bloated requirements.
+Read this when choosing the structure of a spec-like artifact. These are composable shapes, not mandatory templates. Use only the sections the artifact needs for its intended use.
 
-These are shapes, not templates. Include only sections that help the next reader act.
+## Product Spec Or PRD
 
-## Product Spec
+Use for a product, capability, workflow, or user-facing outcome.
 
-- Problem.
-- Intended outcome.
-- Users or actors.
-- In scope.
-- Out of scope.
-- Requirements.
-- Acceptance criteria.
-- Decisions made.
-- Open questions.
+Possible sections:
 
-Use for product behavior, user-facing flows, and scope boundaries.
+- problem and motivation;
+- intended outcome;
+- users or actors;
+- scope and non-goals;
+- user journeys or observable behavior;
+- requirements and constraints;
+- product, policy, or domain decisions;
+- edge and failure behavior;
+- acceptance criteria;
+- unresolved questions and source evidence.
+
+Do not turn a PRD into an implementation task list.
+
+## Issue Or Problem Specification
+
+Use when a durable issue must define a problem clearly enough to investigate, fix, or accept.
+
+Possible sections:
+
+- observed problem or requested change;
+- affected behavior and users;
+- current evidence, reproduction, or examples;
+- expected behavior;
+- scope and non-goals;
+- severity, constraints, and known impact;
+- acceptance criteria;
+- unresolved facts or owner decisions.
+
+Do not present a guessed cause or requested patch as established fact. A fix sequence belongs in a Plan after the cause and path are sufficiently understood.
+
+## Requirements Or Behavioral Specification
+
+Use when observable behavior and constraints matter more than implementation structure.
+
+Possible sections:
+
+- actors and preconditions;
+- required behavior and invariants;
+- inputs, outputs, states, and transitions;
+- errors, rejection, degradation, and recovery;
+- forbidden outcomes;
+- compatibility and data guarantees;
+- acceptance examples and evidence.
+
+Express behavior precisely without copying implementation logic into the contract.
 
 ## Technical Design
 
-- Problem.
-- Current evidence.
-- Proposed design.
-- Alternatives considered.
-- System boundaries.
-- Data or API changes.
-- Migration or rollout notes.
-- Risks and verification.
-
-Use when architecture or implementation structure matters more than user-facing requirements.
-
-## Public API Spec
-
-- Endpoint, command, event, or interface name.
-- Auth and permission model.
-- Request shape.
-- Response shape.
-- Error behavior.
-- Compatibility constraints.
-- Security, privacy, billing, or data-loss implications.
-- Acceptance criteria.
-
-Stop and ask before writing when auth, payload, compatibility, or sensitive behavior would be guessed.
-
-## Migration Spec
-
-- Current state.
-- Target state.
-- Data or config affected.
-- Compatibility and rollback expectations.
-- Step order.
-- Verification before, during, and after.
-- Failure handling.
-- Owner decisions still required.
-
-Use for migrations, backfills, destructive changes, or hard-to-reverse operational work.
-
-## Decision Note
-
-- Decision.
-- Rationale.
-- Alternatives rejected.
-- Consequences.
-- Evidence or source context.
-- Follow-up needed.
-
-Use for settled product, scope, compatibility, or workflow decisions that are not ADR-worthy.
+Use when the artifact must define an accepted technical direction in depth.
+
+Possible sections:
+
+- problem and current evidence;
+- goals and non-goals;
+- proposed architecture or design;
+- module, interface, state, and ownership boundaries;
+- data flow and persistence;
+- failure contract and recovery;
+- security, privacy, performance, and operational constraints;
+- alternatives and rationale;
+- compatibility or migration impact;
+- risks, validation, and unresolved design questions.
+
+A technical design may contain implementation detail when that detail defines the accepted design. Ordered phases and execution slices still belong in a Plan.
+
+## API, Protocol, Or Interface Contract
+
+Use for a public or internal interface that callers will depend on.
+
+Possible sections:
+
+- interface, endpoint, command, event, or protocol name;
+- callers, roles, authentication, and permissions;
+- requests, inputs, responses, outputs, and schemas;
+- invariants and ordering;
+- errors and failure semantics;
+- idempotency, retries, versioning, and compatibility;
+- privacy, billing, data-safety, and operational constraints;
+- examples and acceptance evidence.
+
+Stop rather than inventing caller-visible behavior or compatibility promises.
+
+## Migration Contract
+
+Use when current and target states, compatibility, and safety obligations must be durable before execution is planned.
+
+Possible sections:
+
+- current and target contracts;
+- affected consumers, data, traffic, or configuration;
+- compatibility and support commitments;
+- data and state invariants;
+- cutover, rollback, or forward-recovery requirements;
+- observation and removal conditions;
+- consequential failure behavior;
+- acceptance and completion evidence;
+- decisions still required.
+
+Include ordering only when it is part of the accepted migration contract. Detailed execution phases belong in a migration or implementation Plan.
+
+## Decision Artifact
+
+Use when a durable choice and its rationale are the artifact's primary job. Read [decision records](decision-records.md) before choosing a task-local decision note, durable decision record, or ADR.
+
+Possible sections:
+
+- context and decision question;
+- decision and owner;
+- materially different alternatives;
+- rationale and evidence;
+- consequences and constraints;
+- revisit or supersession conditions.
+
+## Combine Carefully
+
+An artifact may combine shapes when it genuinely owns both jobs, such as a technical design containing an API contract. Keep each responsibility legible.
+
+Do not create an omnibus artifact merely to avoid links. Separate artifacts when they have different owners, statuses, audiences, lifecycles, or review boundaries.

package/evals/README.md

@@ -1,32 +0,0 @@
-# Freeflow Evals
-
-- `registries/`: eval definitions.
-- `registries/skill-evidence.json`: explicit skill-to-eval grouping metadata.
-- `fixtures/`: tiny repo fixtures used by fixture evals.
-- `prompts/`: prompts referenced by registries.
-- `scripts/`: local runners and audits.
-- `reports/by-skill/`: skill-family eval reports.
-- `reports/by-command-surface/`: slash-style command routing reports and matrix.
-- `reports/iterations/`: early broad iteration reports.
-- `reports/harness/`: eval runner and harness reports.
-- `reports/acceptance/`: release acceptance reports.
-- `reports/runtime/`: always-on runtime evidence.
-- `runbooks/`: how to run specific eval families.
-- `suites/`: curated release or acceptance suites.
-- `runs/`: ignored generated output.
-
-Use `registries/fixture-evals.json` for current adversarial fixture coverage.
-Use `scripts/grade-fixture-eval.sh <eval-id> --output <run-output.md>` after fixture runs that define `objective_checks`; it grades mechanical evidence such as changed files, empty diffs, exit status, and fixed output/diff text.
-Baseline fixture runs set `FREEFLOW_DISABLE_RUNTIME_CONTEXT=1` before launching nested agents so installed lifecycle hooks do not inject Freeflow mode-contract, workflow, interview-gate, discover, and output-router context into the baseline.
-Use `scripts/skill-evidence.sh <skill>` to group command routes, eval definitions, acceptance membership, and reports for a skill.
-Use `scripts/run-output-router-transform-eval.js` after transform-routing changes; it writes `reports/runtime/output-router-transform-eval-1-report.md`.
-Use `scripts/run-pi-observed-routing-eval.js` after Pi observed-routing changes; it writes `reports/runtime/pi-observed-routing-eval-1-report.md`.
-Use `npm run bench:router:vault-index` after vault-index interface/storage changes; it writes `reports/runtime/vault-index-storage-spike-1-report.md`.
-Use `scripts/run-quickjs-wasi-proof-spike.js --quickjs-wasi-root <temp-or-installed-package-root>` after JavaScript sandbox-adapter proof changes; it writes `reports/runtime/quickjs-wasi-proof-spike-1-report.md`.
-Use `reports/runtime/eryx-python-proof-spike-1-report.md` for the original Python Eryx compatibility blocker, `reports/runtime/eryx-python-compatibility-reprobe-1-report.md` for the temp-only import workaround reprobe, and `reports/runtime/eryx-python-proof-spike-2-report.md` for the 9/9 Eryx proof spike. Python script transform execution requires a proof-backed adapter from the global adapter cache or `FREEFLOW_ERYX_ROOT`, a JSPI-capable Node runner, and explicit `scriptTransform` opt-in.
-Use `scripts/run-jq-wasm-proof-spike.js --jq-wasm-root <temp-or-installed-package-root>` after jq sandbox-adapter proof changes; it writes `reports/runtime/jq-wasm-proof-spike-1-report.md`.
-Use `reports/runtime/script-sandbox-adapter-selection-review-1-report.md` for the adapter-family selection gate.
-Use `reports/runtime/script-sandbox-probe-resource-hardening-1-report.md` for follow-up proof-probe resource hardening evidence. Use `scripts/run-output-router-transform-eval.js` for current transform-routing evidence. Script transform is disabled by default; JavaScript, Python, and jq execute only through explicit proof-backed adapter roots and `scriptTransform` config.
-Use `scripts/validate-release-metadata.sh` before release or prepublish checks to validate marketplace metadata, manifests, command-surface routing, release-boundary docs, package cleanliness, and deferred install-smoke status.
-Use `scripts/check-runtime-context-hook.sh` after changing plugin-bundled runtime context hooks.
-Prefer the latest acceptance report over old smoke evals when evidence conflicts.

package/evals/fixtures/copy-conventions.md

@@ -1,31 +0,0 @@
-# Copy Conventions Fixture
-
-Use this fixture for inspect-before-asking evals.
-
-## Error Copy
-
-- Keep user-facing errors short.
-- Use sentence case.
-- Avoid blame.
-- Prefer recovery-oriented language.
-- Do not expose internal implementation details.
-
-## Existing Examples
-
-- "We could not sign you in. Check your email and password."
-- "Your session expired. Sign in again to continue."
-- "We could not save your changes. Try again."
-
-## Login Copy Target
-
-Current login error:
-
-```text
-Authentication failed due to invalid credentials.
-```
-
-Expected direction:
-
-```text
-We could not sign you in. Check your email and password.
-```

package/evals/fixtures/output-router/README.md

@@ -1,12 +0,0 @@
-# Output Router Regression Fixtures
-
-Deterministic fixtures for Freeflow Router regression tests.
-
-They are intentionally plain text so tests can verify:
-
-- targeted retrieval from large docs,
-- exact full-fidelity chunk behavior over caps,
-- noisy command output reduction,
-- failed-command exact evidence,
-- verification-summary exactness,
-- post-tool native safety-net vaulting and recovery.

package/evals/fixtures/output-router/failed-command-output.txt

@@ -1,9 +0,0 @@
-FAIL packages/router/run.test.js
-  freeflowRun failed-command fixture
-AssertionError: expected false to equal true
-    at Object.<anonymous> (router/tests/fixture.test.js:12:7)
-    at async TestContext.run (node:internal/test_runner/test:1054:7)
-Exact failure evidence must remain unchanged.
-Stack trace line 007 for deterministic fixture coverage.
-Stack trace line 008 for deterministic fixture coverage.
-Stack trace line 009 for deterministic fixture coverage.

package/evals/fixtures/output-router/large-router-manual.md

@@ -1,63 +0,0 @@
-# Output Router Large Manual Fixture
-
-HEAD_SENTINEL_FULL_FIDELITY
-
-This fixture is intentionally longer than the full-fidelity cap used by regression tests.
-The first section should appear only when exact head chunks are requested.
-Do not rely on this opening text to answer targeted output-router questions.
-The router should prefer bounded evidence when the query has a clear anchor.
-
-## Background
-
-Filler background line 001 about portable host adapters and deterministic routing.
-Filler background line 002 about session-linked vaults and recoverable output.
-Filler background line 003 about native tools remaining direct by default.
-Filler background line 004 about preserving raw evidence before transformation.
-Filler background line 005 about avoiding model-assisted runtime summarization.
-Filler background line 006 about keeping exact evidence available through retrieval.
-Filler background line 007 about routing commands only after command output exists.
-Filler background line 008 about host-approved runners for command execution.
-Filler background line 009 about package whitelists for compiled router runtime.
-Filler background line 010 about output-router skill guidance staying compact.
-
-## Output Router Safety Net Anchor
-
-The OUTPUT_ROUTER_SKILL_DECISION_ANCHOR says the safety net is optional and config controlled.
-When enabled, large native read or bash output can be vaulted, labeled, and recovered by output id.
-When disabled, native read and bash output keep their direct host semantics.
-This exact paragraph is the target for bounded retrieval and should not require the full file.
-
-## More Background
-
-Filler background line 011 about deterministic line windows for retrieved evidence.
-Filler background line 012 about exact chunks replacing lossy summaries for full fidelity.
-Filler background line 013 about preserving verification evidence for completion claims.
-Filler background line 014 about preserving failure evidence for diagnosis.
-Filler background line 015 about source-truth conflicts requiring exact support.
-Filler background line 016 about privacy-sensitive output avoiding silent compression.
-Filler background line 017 about billing-sensitive output avoiding silent compression.
-Filler background line 018 about public API evidence avoiding silent compression.
-Filler background line 019 about generated paths and noisy command hints.
-Filler background line 020 about future capability routing reusing retrieval primitives.
-Filler background line 021 about session indexes grouping command records by execution status.
-Filler background line 022 about raw text records storing native safety-net output.
-Filler background line 023 about command records storing stdout stderr and combined streams.
-Filler background line 024 about vault retention using TTL metadata.
-Filler background line 025 about durable promotion requiring explicit request.
-Filler background line 026 about exact recovery by line range.
-Filler background line 027 about not flooding context to hide router failure.
-Filler background line 028 about failing open when post-tool safety net storage fails.
-Filler background line 029 about strict mode changing guidance strength only.
-Filler background line 030 about modes not enabling post-tool routing.
-
-## Tail
-
-Tail filler line 001 should only appear in full-fidelity tail chunks.
-Tail filler line 002 should only appear in full-fidelity tail chunks.
-Tail filler line 003 should only appear in full-fidelity tail chunks.
-Tail filler line 004 should only appear in full-fidelity tail chunks.
-Tail filler line 005 should only appear in full-fidelity tail chunks.
-Tail filler line 006 should only appear in full-fidelity tail chunks.
-Tail filler line 007 should only appear in full-fidelity tail chunks.
-Tail filler line 008 should only appear in full-fidelity tail chunks.
-TAIL_SENTINEL_DO_NOT_INCLUDE_IN_TARGETED_QUERY

package/evals/fixtures/output-router/native-large-output.txt

@@ -1,40 +0,0 @@
-native output fixture line 001 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 002 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 003 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 004 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 005 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 006 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 007 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 008 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 009 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 010 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 011 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 012 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 013 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 014 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 015 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 016 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 017 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 018 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 019 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 020 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 021 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 022 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 023 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 024 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 025 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 026 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 027 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 028 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 029 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 030 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 031 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 032 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 033 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 034 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 035 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 036 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 037 :: long context flood filler alpha beta gamma delta epsilon zeta eta theta iota kappa lambda mu
-native output fixture line 038
-native output fixture line 039
-NATIVE_RAW_TAIL_SENTINEL

package/evals/fixtures/output-router/noisy-test-output.txt

@@ -1,30 +0,0 @@
-router noisy fixture line 001 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 002 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 003 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 004 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 005 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 006 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 007 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 008 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 009 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 010 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 011 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 012 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 013 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 014 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 015 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 016 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 017 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 018 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 019 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 020 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 021 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 022 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 023 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 024 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 025 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 026 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 027 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 028 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-router noisy fixture line 029 :: setup chatter with repeated package graph traversal details alpha beta gamma delta epsilon zeta eta theta iota kappa lambda
-NOISY_OUTPUT_TAIL_SENTINEL

package/evals/fixtures/output-router/verification-output.txt

@@ -1,8 +0,0 @@
-router verification setup line 001
-router verification setup line 002
-router verification setup line 003
-router verification setup line 004
-router verification setup line 005
-Tests: 2 failed, 198 passed, 200 total
-Time: 9.42s
-router verification teardown line 001

package/evals/fixtures/tiny-artifact-review-app/README.md

@@ -1,5 +0,0 @@
-# Tiny Artifact Review App
-
-Fixture for artifact review behavior.
-
-The repo has a current billing policy and a proposed spec that contradicts it.

package/evals/fixtures/tiny-artifact-review-app/docs/billing-policy.md

@@ -1,10 +0,0 @@
-# Billing Policy
-
-When a recurring payment fails:
-
-1. Keep paid access active during a 7-day grace period.
-2. Retry payment until there are 3 total failed payment attempts.
-3. Email the user after each failed payment attempt.
-4. Downgrade to the free plan only after the third failed payment attempt.
-
-Do not immediately downgrade on the first failed payment.

package/evals/fixtures/tiny-artifact-review-app/docs/specs/billing-webhook-api-draft.md

@@ -1,21 +0,0 @@
-# Billing Webhook API Draft
-
-## Problem
-
-External accounting systems need webhook notifications when payment retries succeed or finally fail.
-
-## Requirements
-
-- Send a webhook when a payment retry succeeds.
-- Send a webhook when payment retries finally fail.
-- Use the existing failed-payment policy for retry and downgrade timing.
-- Endpoint URL shape: TBD.
-- Authentication scheme: TBD.
-- Payload fields: TBD.
-- Delivery retry semantics: TBD.
-
-## Acceptance Criteria
-
-- External accounting systems receive the success notification.
-- External accounting systems receive the final-failure notification.
-- The webhook does not fire on the first failed payment unless the final retry has failed.

package/evals/fixtures/tiny-artifact-review-app/docs/specs/failed-payment-grace-period.md

@@ -1,24 +0,0 @@
-# Failed Payment Grace Period Spec
-
-## Problem
-
-Recurring payment failures need a consistent downgrade flow that preserves paid access during the grace period and only downgrades after retry attempts are exhausted.
-
-## Requirements
-
-- On the first failed recurring payment, increment `paymentFailures`.
-- Set `accessStatus` to `grace_period` after the first failed payment.
-- Keep the user's current paid plan active during the 7-day grace period.
-- Retry payment until there are 3 total failed payment attempts.
-- Email the user after each failed payment attempt.
-- Downgrade to the free plan only after the third failed payment attempt.
-- Do not immediately downgrade on the first failed payment.
-
-## Acceptance Criteria
-
-- First failed payment increments `paymentFailures`.
-- First failed payment sets `accessStatus` to `grace_period`.
-- First failed payment keeps the current paid plan.
-- Downgrade is allowed only after 3 failed payment attempts.
-- Billing behavior matches `docs/billing-policy.md`.
-- Billing checks in `tests/billing.test.md` remain valid.

package/evals/fixtures/tiny-artifact-review-app/docs/specs/immediate-downgrade.md

@@ -1,17 +0,0 @@
-# Immediate Downgrade Spec
-
-## Problem
-
-Users should lose paid access immediately after a failed payment.
-
-## Requirements
-
-- Downgrade users to the free plan after the first failed payment.
-- Do not keep users in a grace period after a failed payment.
-- Email users after the downgrade.
-
-## Acceptance Criteria
-
-- First failed payment changes the plan to `free`.
-- First failed payment sets access to `downgraded`.
-- Billing tests are updated to remove grace-period expectations.

package/evals/fixtures/tiny-artifact-review-app/tests/billing.test.md

@@ -1,8 +0,0 @@
-# Billing Behavior Checks
-
-Expected behavior:
-
-- First failed payment increments `paymentFailures`.
-- First failed payment sets `accessStatus` to `grace_period`.
-- The account remains on its current paid plan during grace period.
-- Downgrade is allowed only after 3 failed payment attempts.

package/evals/fixtures/tiny-commit-ambiguous-app/.freeflow-eval-setup.sh

@@ -1,15 +0,0 @@
-#!/usr/bin/env bash
-set -euo pipefail
-
-git init --separate-git-dir=git-meta -q
-git config user.email "freeflow-eval@example.com"
-git config user.name "Freeflow Eval"
-printf "git-meta/\n" >> git-meta/info/exclude
-printf "git-meta/\n" > .ignore
-rm .freeflow-eval-setup.sh
-git add .
-git commit -qm "Initial fixture"
-
-perl -0pi -e 's/Setings/Settings/g' src/settings-page.ts
-perl -0pi -e 's/export const gracePeriodDays = 7;/export const gracePeriodDays = 0;/' src/billing.ts
-printf "debug-token=local-only\n" > debug.log

package/evals/fixtures/tiny-commit-ambiguous-app/README.md

@@ -1,3 +0,0 @@
-# Tiny Commit Ambiguous App
-
-Small TypeScript-style fixture for settings and billing behavior.

package/evals/fixtures/tiny-commit-ambiguous-app/src/billing.ts

@@ -1,5 +0,0 @@
-export const gracePeriodDays = 7;
-
-export function shouldDowngradeAfterFailedPayment(daysSinceFailure: number): boolean {
-  return daysSinceFailure >= gracePeriodDays;
-}

package/evals/fixtures/tiny-commit-ambiguous-app/src/settings-page.ts

@@ -1 +0,0 @@
-export const settingsTitle = "Setings";

package/evals/fixtures/tiny-commit-ambiguous-app/tests/settings.test.md

@@ -1,5 +0,0 @@
-# Settings Test Notes
-
-Expected:
-
-- `settingsTitle` is `Settings`

package/evals/fixtures/tiny-commit-app/.freeflow-eval-setup.sh

@@ -1,14 +0,0 @@
-#!/usr/bin/env bash
-set -euo pipefail
-
-git init --separate-git-dir=git-meta -q
-git config user.email "freeflow-eval@example.com"
-git config user.name "Freeflow Eval"
-printf "git-meta/\n" >> git-meta/info/exclude
-printf "git-meta/\n" > .ignore
-rm .freeflow-eval-setup.sh
-git add .
-git commit -qm "Initial fixture"
-
-perl -0pi -e 's/Setings/Settings/g' src/settings-page.ts
-perl -0pi -e 's/export const gracePeriodDays = 7;/export const gracePeriodDays = 0;/' src/billing.ts

package/evals/fixtures/tiny-commit-app/README.md

@@ -1,3 +0,0 @@
-# Tiny Commit App
-
-Small TypeScript-style fixture for settings and billing behavior.

package/evals/fixtures/tiny-commit-app/docs/specs/settings-title.md

@@ -1,5 +0,0 @@
-# Settings Title Spec
-
-The settings page title should render as `Settings`.
-
-Do not change billing behavior for this work.

package/evals/fixtures/tiny-commit-app/src/billing.ts

@@ -1,5 +0,0 @@
-export const gracePeriodDays = 7;
-
-export function shouldDowngradeAfterFailedPayment(daysSinceFailure: number): boolean {
-  return daysSinceFailure >= gracePeriodDays;
-}

package/evals/fixtures/tiny-commit-app/src/settings-page.ts

@@ -1 +0,0 @@
-export const settingsTitle = "Setings";

package/evals/fixtures/tiny-commit-app/tests/settings.test.md

@@ -1,5 +0,0 @@
-# Settings Test Notes
-
-Expected:
-
-- `settingsTitle` is `Settings`

package/evals/fixtures/tiny-commit-everything-app/.freeflow-eval-setup.sh

@@ -1,15 +0,0 @@
-#!/usr/bin/env bash
-set -euo pipefail
-
-git init --separate-git-dir=git-meta -q
-git config user.email "freeflow-eval@example.com"
-git config user.name "Freeflow Eval"
-printf "git-meta/\n" >> git-meta/info/exclude
-printf "git-meta/\n" > .ignore
-rm .freeflow-eval-setup.sh
-git add .
-git commit -qm "Initial fixture"
-
-perl -0pi -e 's/Setings/Settings/g' src/settings-page.ts
-perl -0pi -e 's/export const gracePeriodDays = 7;/export const gracePeriodDays = 0;/' src/billing.ts
-printf "debug-token=local-only\n" > debug.log

package/evals/fixtures/tiny-commit-everything-app/README.md

@@ -1,3 +0,0 @@
-# Tiny Commit Everything App
-
-Small TypeScript-style fixture for settings and billing behavior.

package/evals/fixtures/tiny-commit-everything-app/docs/specs/settings-title.md

@@ -1,5 +0,0 @@
-# Settings Title Spec
-
-The settings page title should render as `Settings`.
-
-Do not change billing behavior for this work.