1.  Two Goals

Spec_driven_TextFinder builds a command-line search utility from its specifications. The project pursues two goals, and this page set is organized around them rather than around the specification's own section numbers.

1. Explain the spec-driven process as practiced here. What authority each document holds, the order the documents come in, and how a correction reaches the code.
2. Explain the code structure and functionality. What TextFinder does at its boundaries, and how one language's implementation satisfies that.

Each goal splits in two. The project-level part is language-agnostic: it holds for every implementation. The per-language part covers one implementation's own documents and code. Four parts, six threads.

2.  What Spec-Driven Means Here

The specifications are the source the code derives from, not a description written after the fact. Constitution.md states the rule in one sentence: all code creation and modification derives from the Spec*.md and *Structure.md files in the project tree. Changing the code starts with changing one of those documents. Two consequences run through every page here. An ambiguous specification is a question to ask rather than a gap to fill from a sample implementation, so the prompt records carry long lists of questions and the answers they drew. And the same specification binds four languages, so a rule that would let two implementations drift apart gets moved up to the project level, where it binds all of them at once. The C++, Rust, and C# implementations are complete and each thread carries eight pages. Python follows. Its entry in the header row above is disabled until its pages exist.

3.  The Six Threads

A thread is a set of pages a reader steps through in order. The #pages menu and the Prev Page / Next Page controls operate on one thread at a time, and the header row above crosses from one thread to another. This page is page 0 of the Process thread, so Next Page walks the process from the beginning.

Thread	Pages	Goal	Covers
Process	5	1a	The constitution, how the project specification was written, the five document kinds and the citation chain, and the two documents that govern the generated prose
Behavior	5	2a	What every TextFinder does, decomposed by the boundaries the program has: the command line, traversal and file selection, matching and output, and the interface and portability contracts
C++	8	1b, 2b	The process applied to C++, then structure, the binary, the three libraries, the test suites, and the executable run against this project's own tree
Rust	8	1b, 2b	The same eight parts in a Cargo workspace of three library crates and one binary, with the audit that reshaped them and the parent specification they changed
C#	8	1b, 2b	The same eight parts in a solution of three class libraries and one console binary, with the four decisions the parent specification delegates to a component spec
Python	—	1b, 2b	Pending

The Process and Behavior threads both draw on Spec_TextFinder.md, from different angles. Process treats it as an artifact: how it was written, what authority it holds, what cites it. Behavior treats it as a design: what the program does at its boundaries. Neither thread restates the other. A language thread carries both per-language parts, because the conversations that produced a language's specifications and the code those specifications fixed are read together. Page 0 of a language thread is the process page; pages 1 through 7 are the code pages, in dependency order.

4.  Documents and Their Order

Five kinds of document sit in the project tree, and the order matters: each one narrows what the next may decide.

Document	What it fixes
Constitution.md	The two rules that bind the whole tree
Spec_TextFinder.md	Behavior common to every implementation, in no particular language
[lang]_TextFinder_Structure.md	Components, dependency direction, and build, for one language
Spec_*.md	One per component: the interface in the target language
Prompts_*.md	Records of the conversations that produced the others

Prompts_*.md files are records, not inputs to code. Constitution.md says so explicitly, which is what keeps a design conversation from becoming an unwritten requirement. Every page but this one carries the records for the documents it discusses, in collapsed blocks at the end, so the page reads without them and opens to them on demand.

5.  How to Move Through the Pages

A reader moves in three directions, and the explorer's control panel supplies a mechanism for each.

Direction	Mechanism	Scope
Within a page	the #sections menu, Prev Sect / Next Sect	the page's numbered sections
Within a thread	the #pages menu, Prev Page / Next Page	the thread's ordered pages
Across threads	the header row at the top of every page	the same subject in another thread

The header row follows one rule: cross to the same subject where it exists, and to the thread's first page where it does not. From the C++ Cmdline page, the Behavior entry reaches the page that fixes what every command-line parser must do; from a Process page, each language entry reaches that language's own process page. The entry for the thread a reader is already in points at that thread's first page, which gives every page a one-click route back to the top of its own thread. Three pages are worth reading first, whatever a reader came for:

• The Constitution - the two rules, and what each deliberately permits.
• What TextFinder Does - the utility in one page.
• C++ Demonstration - the built executable run against this project's own tree.