project-logbook 1.0.0 → 1.2.0

package/src/templates/index.md

@@ -2,7 +2,7 @@
 # The ticket field should match the ID portion (e.g., LB-34)
 ticket: {{id}}
 # The title should be a human-readable description of the work
-title: {{title}}
+title: {{yamlTitle}}
 prompter: "[PROMPTER]"
 harness: "[HARNESS]"
 llm: "[LLM]"
@@ -27,9 +27,10 @@ TODO: Write a polished, highly readable ticket summary that reads like an engagi
 
 ### Formatting & Style Rules:
 - **Maintain the narrative tone:** TODO: Keep the storytelling flair (e.g., describing how problems accumulated or how gaps surfaced), but stay strictly factual based on the provided changes.
-- **Add thematic headings:** TODO: Break the narrative down into logical chapters using Markdown headings (e.g., ### The Friction Points, ### The Fix, ### Closing the Gap).
-- **Use bullet points:** TODO: Whenever listing multiple items (like friction points, test scenarios, or rewritten paths), use a bulleted list instead of a dense paragraph to make it scannable.
+- **Add thematic headings:** TODO: Break the narrative down into logical chapters using action-oriented Markdown subheadings that describe what was improved/solved (e.g., ### Improving TabGroup Accessibility, ### Binding Dialog Colors to the Theme) rather than dry, generic headers like "Friction" or "The Fix".
+- **Avoid forced bullet points:** TODO: Write in natural, flowing paragraphs (like in a dev blog post). Only use bullet points for actual, simple lists of items (e.g., list of modified files or configuration options), never to structure or split your main story thoughts.
 - **Use bold emphasis:** TODO: Bold key concepts, problems, and solutions to guide the reader's eye.
 - **Format code:** TODO: Use inline backticks for files, plugins, HTML elements, and code snippets (e.g., `src/lib/build-helpers.ts`).
-- **Keep paragraphs short:** TODO: Ensure no paragraph is longer than 3-4 sentences. Keep the pacing quick and engaging.
+- **Keep paragraphs short:** TODO: Ensure no paragraph is longer than 4 sentences. Keep the pacing quick and engaging.
+- **Weave the narrative:** TODO: Do not list all friction points in one massive block followed by all fixes/solutions in another. Instead, weave them together chronologically or by component/theme (e.g., describe the friction and its corresponding fix within the same chapter or paragraph).
 - **Do not state the obvious**: TODO: Passed tests, lints, pre-commit suites are mandatory and no ticket is released without this. This does not need to be mentioned

package/src/templates/log.md

@@ -1,4 +1,4 @@
-# Technical Log: {{id}}-{{slug}}
+# Technical Log: {{id}} - {{title}}
 
 > **REMINDER**: Log your work in real-time using `logbook log "<message>"`. Don't wait until the end!
 > 

package/src/templates/steer.txt

@@ -33,9 +33,22 @@ You MUST log your work continuously using `logbook log "<message>"`. This is not
 Phase 3: Synthesize
 1. When implementation is finished, write the narrative in `index.md`.
 2. Storytelling Mode: Explain the "Why" and the "Journey." Avoid simple technical bullet points.
+   - **Keep paragraphs short**: Max 4 sentences per paragraph to ensure fast-paced, readable prose.
+   - **Use bold & code formatting**: Use inline backticks for files/code, and bolding for key terms/problems.
+   - **Structure with H3 headings**: Use action-oriented subheadings describing the topic/component modified (e.g., ### Improving TabGroup Accessibility, ### Binding Dialog Colors to the Theme) instead of generic "Friction" or "Fix" headers.
+   - **Avoid forced lists**: Write in natural, flowing paragraphs. Only use bullet points for simple lists of items (e.g., files modified, options checked), never to split or structure your core narrative thoughts.
+   - **Weave friction & fix**: Do not separate all problems into one block and all solutions into another. Weave them together chronologically or group them by component/theme.
 3. Clean up all template placeholders and complete the frontmatter (author, summary, dates).
 
 Phase 4: Verify
 1. Run `npm run pre` (which includes `logbook lint` and other quality gates).
 2. Ensure there are no linter errors, unreplaced placeholders, or architectural violations before concluding your work. 
-3. Hand back to the prompter, who will review and run `logbook release`.
+3. Hand back to the prompter for local QA/review.
+
+Phase 5: Local QA & Iterative Refinement
+1. Expect feedback loops: The prompter will test your changes, challenge decisions, and request refinements.
+2. In each iteration loop:
+   - Log decisions and pivots in `log.md` in real-time (`logbook log "<message>"`).
+   - Update the story in `index.md` to reflect any design/code changes.
+   - Run verification again (`npm run pre`).
+3. Optimize the git commit message (conforming to project standards) before final release.

package/src/templates/styles.css

@@ -169,6 +169,38 @@ main {
   transform: translateX(4px);
 }
 
+.teaser-image-right {
+  flex-shrink: 0;
+  max-width: 200px;
+  max-height: 120px;
+  display: flex;
+  align-items: center;
+  justify-content: center;
+  overflow: hidden;
+  border-radius: 4px;
+}
+
+.teaser-image-right img {
+  max-width: 100%;
+  max-height: 100%;
+  object-fit: contain;
+}
+
+.teaser-image-bottom {
+  margin-top: 0.75rem;
+  display: flex;
+  justify-content: center;
+  align-items: center;
+  width: 100%;
+}
+
+.teaser-image-bottom img {
+  max-width: 100%;
+  max-height: 200px;
+  object-fit: contain;
+  border-radius: 4px;
+}
+
 /* Post Page */
 .back-link {
   display: inline-flex;