Crucible Quest

Tracks

1. 01🧭The Task Is Already Clear

   0/4 lessons

   Generic starts after scope; otherwise the queue is only a prettier ambiguity

   Crucible accepts any task shape, but it does not accept the absence of one. This track draws the line that keeps a generic workshop from becoming a product-discovery fog: scope, destination, and done conditions arrive before queue entry. It then defends the permanent oneoff pipeline as the honest default, shows why a brief is an input rather than a conversation the engine secretly continues, and returns ownership of completion to the task itself.

   Lesson list (4)

   • 01
     Generic Does Not Mean Vague~11 min · scope, generic-work, intake, boundaries
   • 02
     Oneoff Is a Real Pipeline~11 min · oneoff, pipeline, defaults, honesty
   • 03
     Scope Is an Input~11 min · brief, scope, immutability, ownership
   • 04
     Done Belongs to the Task~11 min · acceptance, destination, proof, completion

   ✓Quiz · 4 questions→

2. 02🧩One Kernel, Many Workshops

   0/4 lessons

   Reuse the queue machinery only after two real crafts prove the seam

   Generic does not mean monolithic. A concrete workshop still owns its product boundary, while queue, claims, pipelines, launch tickets, and review plumbing may become a reusable kernel once a second workshop proves they are identical in behavior. This track shows the root-class shape, the second-use extraction rule, the boundary tests that keep domain language out of the kernel, and the live-provider pattern that lets applications stay thin without becoming hollow wrappers.

   Lesson list (4)

   • 01
     Root Class, Concrete Workshops~11 min · architecture, kernel, boundaries, workshops
   • 02
     Extract at Second Use~11 min · reuse, duplication, evidence, refactoring
   • 03
     Boundaries Before Reuse~11 min · api-design, domain-language, coupling, contracts
   • 04
     Live Provider, Thin Client~11 min · provider, runtime, configuration, clients

   ✓Quiz · 4 questions→

3. 03🗃️Pipelines Are Rows

   0/5 lessons

   The craft lives in editable, versioned data—not in another fork of the application

   A Crucible pipeline is a database row: name, presentation, brief template, required stages, review default, optional brain hint, version, and archival state. That choice makes new task shapes ordinary data instead of code deployments. This track builds the row model, defends the seeded oneoff, separates live catalog edits from frozen run history, and draws the sharp lifecycle boundary between archive and delete.

   Lesson list (5)

   • 01
     Craft Is Data~12 min · pipeline-rows, schema, policy, data
   • 02
     The Seeded Oneoff~12 min · oneoff, seed-data, invariant, fallback
   • 03
     Version the Future~12 min · versioning, briefs, history, live-policy
   • 04
     Archive, Do Not Erase~12 min · archive, history, referential-integrity, lifecycle
   • 05
     Delete Only Before History~12 min · delete, safety, references, mutations

   ✓Quiz · 4 questions→

4. 04🧊Frozen Work Orders

   0/4 lessons

   The brief and its material become evidence only when mutation stops at take

   A queue note becomes an executable work order only after the workshop materializes it with a pipeline version and attachment manifest. Until take, the requester may correct or replace that package. At take, mutation stops: the session must be reviewable against exactly what it received. This track connects brief snapshots, queued-only edits, engine-owned attachment storage, and content hashes into one proof boundary.

   Lesson list (4)

   • 01
     Materialize the Brief~12 min · brief, materialization, snapshot, handoff
   • 02
     Queued Can Change; Taken Cannot~12 min · state-machine, mutation, take, immutability
   • 03
     Attachments Cross the Boundary~12 min · attachments, storage, manifest, retention
   • 04
     Freeze Proves What You Saw~12 min · hashes, evidence, review, integrity

   ✓Quiz · 4 questions→

5. 05🚪Take, Stage, Gate

   0/5 lessons

   A live session earns authority through a claim and proves progress through named transitions

   Queue state is not enough. Take must bind one live session to one delegation; the plan gate must expose premises before mutation; stage entries must record what actually closed; and verification must read the pipeline contract rather than trust a narration. This track makes hints, launch convenience, claims, stages, and gates occupy their proper authority levels.

   Lesson list (5)

   • 01
     A Claim Binds a Session~12 min · claim, session, concurrency, ownership
   • 02
     The Plan Gate Is Not Decoration~12 min · plan-gate, approval, premises, method
   • 03
     Stage Logs Are Evidence~12 min · stages, provenance, events, audit
   • 04
     Brain Hints Are Not Authority~12 min · brain-routing, capabilities, launch, policy
   • 05
     Verify Reads the Contract~12 min · verification, required-stages, gates, landing

   ✓Quiz · 4 questions→

6. 06🔍Review, Revise, Stet

   0/5 lessons

   Independent rejection has value only when every finding reaches a visible disposition

   Review is a separate executable looking cold at the frozen artifact and approved plan. It returns blockers and observations, not a mood. The author repairs valid blockers, rejects invalid ones with an evidenced stet, and stops at a declared round budget rather than recursing until a model says nothing. This track turns disagreement into an auditable work product.

   Lesson list (5)

   • 01
     Review Is a Separate Program~12 min · review, independence, cli, cold-context
   • 02
     Blockers and Observations~12 min · findings, severity, review-contract, evidence
   • 03
     Revise the Artifact, Not the Score~12 min · revision, repair, verification, quality
   • 04
     Stet With a Reason~12 min · stet, disagreement, evidence, accountability
   • 05
     Round Budgets End Recursion~12 min · round-budget, termination, review, risk

   ✓Quiz · 4 questions→

7. 07🧾Land the Record

   0/4 lessons

   The deliverable goes where the task promised; Crucible closes the auditable trail beside it

   Generic work does not share one destination, so Crucible cannot make a repository commit the universal result. It requires a landing summary and task acceptance evidence, accepts a commit only when the deliverable naturally has one, persists companion artifacts before referencing them, and keeps an append-only truth with a queryable mirror. This track makes record-only landings first class without weakening proof.

   Lesson list (4)

   • 01
     The Deliverable Lands Elsewhere~11 min · destination, product-boundary, delivery, records
   • 02
     Summary Required, Commit Optional~11 min · summary, commit, non-code-work, proof
   • 03
     Companions Before the Record~11 min · ordering, artifacts, atomicity, landing
   • 04
     One Writer, Two Views~11 min · single-writer, jsonl, sqlite, projection

   ✓Quiz · 4 questions→

8. 08🪜Promote or Graduate

   0/5 lessons

   A second occurrence earns a row; a domain that outgrows the row may earn a workshop

   The final track turns recurrence into a product ladder. Compare two oneoff records before naming a shape, use the live pipeline-create path rather than teaching an unbuilt convenience verb, keep work in Crucible while a row can express the craft, and graduate only when the domain needs lifecycle, state, UI, or operational ownership of its own. The capstone makes the decision from evidence rather than prestige.

   Lesson list (5)

   • 01
     The Second-Use Test~12 min · recurrence, promotion, comparison, evidence
   • 02
     Pipeline Create Is Promotion Today~12 min · pipeline-create, current-state, versioned-rows, operations
   • 03
     When a Row Is Enough~12 min · right-sizing, configuration, generic-workshop, boundaries
   • 04
     When a Workshop Is Earned~12 min · product-boundary, graduation, domain-state, operations
   • 05
     Build the Ladder~12 min · capstone, decision-making, architecture, provenance

   ✓Quiz · 4 questions→