create-pathfinder 1.7.0 → 2.0.0

package/context/current-feature.md

@@ -1,46 +0,0 @@
-# Current Feature
-
-Use this as the lean tracker for active work.
-
-## Status
-
-- State: `[not started / loaded / in progress / blocked / ready for review / complete]`
-- Feature spec: `[context/features/##-feature-name.md]`
-- Current delivery chunk: `[number and name]`
-- Git state: `[branch/ref and working-tree summary, following project policy]`
-
-## Goal
-
-- `[single feature outcome]`
-
-## Active Delivery Chunk
-
-- `[small stable increment being implemented now]`
-
-## Context Boundary
-
-Read:
-
-- `[required file or folder]`
-
-Avoid loading:
-
-- `[unrelated area]`
-
-## Definition of Done
-
-- `[acceptance result]`
-- `[verification]`
-- `[required docs/state update]`
-
-## Assumptions and Open Questions
-
-- `[assumption or none]`
-
-## Out of Scope
-
-- `[explicit boundary]`
-
-## Up Next
-
-- `[next chunk or feature]`

package/context/features/example-feature-spec.md

@@ -1,103 +0,0 @@
-# Example Feature Spec
-
-> A worked example of the shape `to-specs` writes into this folder. Real
-> specs are new files here, titled with the feature's own name; copy
-> `templates/feature-spec.template.md` to start one.
-
-## Status
-
-Not Started
-
-## Overview
-
-Describe the smallest coherent outcome, where it fits, and why it matters.
-
-## Problem
-
-- What is missing, risky, confusing, inaccessible, unreliable, or inefficient?
-- Who or what is affected?
-- Why does this matter now?
-
-## Goal
-
-State one user-visible or system-verifiable outcome.
-
-## Dependencies
-
-- Earlier feature, system, decision, prototype, or `None`.
-
-## Requirements
-
-- Requirement 1
-- Requirement 2
-- Requirement 3
-- Include relevant failure, permission, loading, empty, retry, responsive, accessibility, operational, or compatibility states only when applicable.
-
-## Out of Scope
-
-- Explicit exclusion
-- Later feature, if known
-- Unrelated refactors, dependencies, or polish
-
-## Experience or Operational Notes — When Applicable
-
-- User interaction, system behavior, responsive behavior, accessibility, observability, performance, security, or operational expectations.
-
-## Technical Notes
-
-Likely areas:
-
-- `[specific path or bounded area]`
-
-Implementation constraints:
-
-- Follow project context and approved prototype direction.
-- Do not silently resolve open architecture decisions.
-- Keep prototype and production code boundaries explicit.
-
-## Context Boundary
-
-Read:
-
-- `[specific context and code]`
-
-Avoid loading:
-
-- `[unrelated systems, old specs, generated output]`
-
-Split this feature further if its required context is not focused enough for reliable implementation and verification.
-
-## Delivery Chunks
-
-1. `[stable, verifiable increment]`
-2. `[stable, verifiable increment]`
-3. `[optional stable increment]`
-
-Each chunk should leave the project stable.
-
-## Acceptance Criteria
-
-- The defined outcome works end to end within scope.
-- Relevant failure and edge behavior is handled.
-- Applicable quality requirements are met.
-- Required automated/manual checks pass.
-- The work can be reviewed independently.
-
-## Verification
-
-- Manual or operational checks:
-- Automated checks:
-- Edge cases:
-- Quality checks:
-
-## Learning Targets
-
-- Concepts worth explaining after completion:
-- Diagram or demonstration opportunity:
-- Quiz ideas:
-
-## Suggested Delivery Metadata
-
-- Git action: `[follow project workflow]`
-- Suggested branch, when applicable: `[project naming convention]`
-- Suggested commit, when applicable: `[project convention]`

package/context/history.md

@@ -1,14 +0,0 @@
-# Project History
-
-Append-only record of completed, accepted work. Prefer durable outcomes over raw file inventories.
-
-## Completed Work
-
-### [YYYY-MM-DD] — [Feature or milestone]
-
-- Outcome:
-- Why it mattered:
-- Verification:
-- Important decision or tradeoff:
-- Learning artifact, if any:
-- Follow-up, if any:

package/context/learning/learner-profile.md

@@ -1,35 +0,0 @@
-# Learner Profile
-
-## Current Level
-
-- Primary role: Senior Frontend Engineer
-- Strongest areas: React, TypeScript, reusable components, design systems, frontend testing
-- Areas to strengthen: system design, complex state, server-state architecture, data visualization, performance at scale, enterprise product architecture, backend integration, real-time systems
-- Target role or environment: Senior frontend/product engineering role building complex enterprise interfaces
-- Preferred learning style: practical explanations grounded in real code, diagrams, comparisons, interview framing, and short challenges
-- Explanation depth: advanced but do not skip fundamentals that affect architectural decisions
-
-## Learning Preferences
-
-- Explain why a solution was selected, not only what the code does.
-- Compare at least one credible alternative when the tradeoff is meaningful.
-- Connect frontend details to system-level consequences.
-- Include accessibility, performance, testing, and maintainability.
-- Use concise Mermaid diagrams when they clarify data or event flow.
-- Prefer varied assessments: prediction, debugging, design choice, code reading, and transfer.
-- Avoid trivia and syntax-only questions unless syntax caused a real issue.
-- Do not overpraise. Give precise feedback.
-
-## Career Preparation
-
-For relevant lessons, include:
-
-- A likely senior frontend interview question
-- A concise strong-answer outline
-- One follow-up question that tests deeper understanding
-- Vocabulary worth using accurately
-- Any gap between the current implementation and production-scale expectations
-
-## Update Rules
-
-Update this file only when the user explicitly changes learning goals or when a repeated pattern is clearly established across multiple lessons.

package/context/learning/progress.md

@@ -1,28 +0,0 @@
-# Learning Progress
-
-This file records demonstrated understanding, not feature completion.
-
-## Confidence Scale
-
-- `introduced` — explained once; no evidence of recall yet
-- `practiced` — answered or applied with help
-- `independent` — applied correctly without meaningful help
-- `transferable` — applied the concept correctly in a different context
-- `review-needed` — misunderstanding or weak recall was observed
-
-## Concept Records
-
-| Concept | Status | Evidence | Last reviewed | Next reinforcement |
-| --- | --- | --- | --- | --- |
-
-## Lessons Completed
-
-| Date | Feature | Lesson | Quiz result | Challenge result | Follow-up |
-| --- | --- | --- | --- | --- | --- |
-
-## Rules
-
-- Do not mark a concept `independent` from passive reading.
-- Do not mark a concept `transferable` using the same example that introduced it.
-- Record uncertainty honestly.
-- Prefer a few meaningful concepts over dozens of shallow entries.

package/context/project-overview.md

@@ -1,211 +0,0 @@
-# Project Overview
-
-> Describe the product, audience, intended feeling, and reason it should exist.
-
-## Status
-
-- Project: `[Project Name]`
-- Stage: `[idea / prototype / MVP / production / maintenance]`
-- Repo type: `[new / existing / application / library / service / monorepo / other]`
-- Primary goal: `[success definition]`
-- Prototype status: `[not required / recommended / in progress / approved / rejected / TBD]`
-
-## Decision States
-
-These four words describe a decision:
-
-- `TBD` — human decision required
-- `None` — intentionally excluded
-- `N/A` — not applicable
-- `Deferred` — intentionally postponed
-
-## Record Status
-
-A `Status` column describes the record, not the decision:
-
-- `proposed` — written down, not yet approved by the human
-- `accepted` — approved by the human
-- `superseded` — replaced by a later decision, kept for history
-
-The two answer different questions. `TBD` says nobody has decided yet. `proposed` says something was recorded for the human to approve. A recorded proposal is not an approved decision.
-
-## Product Vision
-
-- Problem:
-- Primary user:
-- First useful outcome:
-- Distinctive quality:
-- What this must avoid becoming:
-
-## MVP Boundary
-
-### In scope
-
-- `[essential outcome]`
-
-### Out of scope
-
-- `[deferred outcome]`
-
-### Success signals
-
-- `[observable user, business, system, or learning signal]`
-
-## Core Experience or System Flow
-
-```text
-starting state -> action/process -> useful result -> reason to return or continue
-```
-
-## Requirements, Preferences, Constraints, and Open Decisions
-
-| Type | Item | Notes |
-| --- | --- | --- |
-| Requirement | `[must be true]` | |
-| Preference | `[desired but negotiable]` | |
-| Constraint | `[limit or external obligation]` | |
-| Open decision | `[TBD]` | |
-
-## Recommended and Approved Technology
-
-Recommended and approved choices both live here. `debate-me` and `kickstart-pathfinder` may record a choice before the human approves it; that row is marked `proposed` in `Status` and stays that way until it is `accepted`. Leave `Status` empty while the choice is still `TBD`.
-
-| Layer | Choice | Reason | Status |
-| --- | --- | --- | --- |
-| Platform/runtime | `TBD` | | |
-| Language(s) | `TBD` | | |
-| UI/presentation | `TBD / N/A` | | |
-| Backend/application layer | `TBD / None` | | |
-| Data storage | `TBD / None` | | |
-| Data access/ORM | `TBD / None` | | |
-| Authentication | `TBD / None` | | |
-| Authorization | `TBD / None` | | |
-| API/integration style | `TBD / None` | | |
-| State management | `TBD / N/A` | | |
-| Testing | `TBD` | | |
-| Build/package tooling | `TBD` | | |
-| Deployment/runtime environment | `TBD` | | |
-| Observability | `TBD / Deferred` | | |
-| AI providers/models | `TBD / None` | | |
-
-## Architecture
-
-- Architecture style: `TBD`
-- Repository shape: `TBD`
-- Main boundaries/modules:
-- Data/control flow:
-- Important tradeoffs:
-
-```text
-[path or module]    # purpose
-[path or module]    # purpose
-```
-
-## Prototype Direction
-
-- Prototype needed: `[yes / no / TBD]`
-- Type: `[experience / technical / diagram / mixed / N/A]`
-- Assumption being validated:
-- Output location:
-- Review criteria:
-- Approved direction:
-- Elements explicitly not adopted into production:
-
-## Delivery Workflow
-
-| Area | Choice |
-| --- | --- |
-| Git workflow | `TBD` |
-| Default/stable branch | `TBD` |
-| Branch naming | `TBD / N/A` |
-| Commit convention | `TBD / None` |
-| Pull request policy | `TBD` |
-| Merge strategy | `TBD` |
-| CI/CD | `TBD / None` |
-| Versioning | `TBD / None` |
-| Changelog | `TBD / None` |
-| Release process | `TBD / None` |
-
-## Environments and Integrations
-
-| Area | Choice | Notes |
-| --- | --- | --- |
-| Local development | `TBD` | |
-| Preview/staging | `TBD / None` | |
-| Production | `TBD / None` | |
-| Environment configuration | `TBD` | |
-| Secrets management | `TBD / N/A` | |
-| External APIs/services | `TBD / None` | |
-| Rate/cost limits | `TBD / N/A` | |
-
-## Quality Priorities
-
-Rank only what matters for this project.
-
-1. `[priority]`
-2. `[priority]`
-3. `[priority]`
-
-| Concern | Target or decision |
-| --- | --- |
-| Correctness/reliability | `TBD` |
-| Security/privacy | `TBD / N/A` |
-| Accessibility | `TBD / N/A` |
-| Performance | `TBD / N/A` |
-| Browser/platform support | `TBD / N/A` |
-| Localization | `TBD / None` |
-| Offline behavior | `TBD / N/A` |
-
-## Core Domain Concepts
-
-Describe durable concepts without assuming a language:
-
-```text
-Entity/Concept: Example
-Required fields: id, name
-Important states: draft, active, archived
-Relationships: belongs to / contains / references
-```
-
-## Build, Test, and Run Commands
-
-```text
-install: TBD
-run/dev: TBD
-test: TBD
-lint/static analysis: TBD
-build/package: TBD
-other verification: TBD
-```
-
-## Build Phases
-
-| Phase | Goal | Visible or verifiable win |
-| --- | --- | --- |
-| 1 | Foundation | `[result]` |
-| 2 | Core experience/system | `[result]` |
-| 3 | Real data/integration | `[result]` |
-| 4 | Quality and release readiness | `[result]` |
-
-## Learning Goals
-
-- What the human wants to understand:
-- Preferred lesson format: `[HTML / MDX / Markdown / existing docs system / TBD]`
-- Quiz preferences:
-- Topics to emphasize:
-- Topics to avoid over-explaining:
-
-## Durable Decisions
-
-| Date | Decision | Reason | Status |
-| --- | --- | --- | --- |
-| `[YYYY-MM-DD]` | `[decision]` | `[reason]` | `[proposed / accepted / superseded]` |
-
-## Things To Avoid
-
-- Building before critical decisions are understood.
-- Treating recommendations as approval.
-- Silently resolving `TBD` items.
-- Turning prototype shortcuts into production defaults.
-- Over-documenting temporary implementation detail.
-- Creating feature specs too large for a focused LLM context window.

package/templates/progress-entry.template.md

@@ -1,23 +0,0 @@
-## Progress Update — [Date]
-
-### Lesson
-
-- Feature:
-- Lesson file:
-- Evidence reviewed:
-
-### Concepts
-
-| Concept | Previous | New | Evidence |
-| --- | --- | --- | --- |
-
-### Misconceptions or Gaps
-
-- Gap:
-- Correction:
-- Recommended reinforcement:
-
-### Next Review
-
-- Topic:
-- Suggested timing or trigger: