STD-014: Worklog System

The daily worklog is the foundation of the documentation system. Every workday produces a single capture file that records decisions, accomplishments, blockers, and forward momentum. Over time, worklogs become the primary source for monthly summaries, project timelines, pattern extraction, and case study creation. Without consistent daily capture, institutional knowledge decays within days.

Principles

  1. One worklog per day. Each workday produces exactly one WRKLOG-YYYY-MM-DD.adoc file. Weekend and personal sessions follow the same format. No day produces two worklogs; no worklog spans two days.

  2. Section includes for modularity. The worklog body is composed from section partials (partials/worklog/). Each section is a separate file that is rewritten daily. This enables selective inclusion, independent editing, and partial reuse without modifying the worklog page itself.

  3. Summary first. The worklog opens with a bold day name and a dense paragraph summarizing the entire day’s output. A reader who reads only the summary should understand the day’s scope and significance.

  4. Session accomplishments capture AI-assisted work. Every Claude Code session that produces material output is documented under "Session Accomplishments" with scope, file counts, and line counts where relevant. This is the audit trail for AI-assisted productivity.

  5. TODOs carry forward. The "Today’s Remaining TODO" section uses Must/Should/Stretch tiers. Uncompleted items carry forward to the next worklog or are promoted to a tracker. Nothing silently disappears.

Worklog Naming

Worklogs follow the WRKLOG prefix defined in STD-003:

WRKLOG-YYYY-MM-DD.adoc

Filed in the chronological directory structure:

pages/YYYY/MM/WRKLOG-YYYY-MM-DD.adoc

Example: pages/2026/04/WRKLOG-2026-04-06.adoc

Creation

make new-day

This command:

  1. Updates antora.yml daily attributes (current-day, current-date, current-worklog) via make update-today-attrs

  2. Updates carryover day counts via make update-days

  3. Creates the worklog file with correct header, section includes, and TODO skeleton

The daily attribute update keeps the landing page (index.adoc) current automatically — the "Today" section uses include::partial$home-today.adoc[] which references {current-worklog} and {current-month} attributes. Never create worklogs manually — the Makefile template ensures structural consistency.

For local preview:

make serve    # Build + local server (port 8000)
make          # Build only

Required Structure

Every worklog MUST follow this structure exactly:

= WRKLOG-YYYY-MM-DD
:description: [Day Name] - [Summary of day's work]
:revdate: YYYY-MM-DD

== Summary

include::partial$worklog/urgent.adoc[]

include::partial$worklog/morning.adoc[]

include::partial$worklog/work-chla.adoc[]

== Session Accomplishments (Claude Code)

include::partial$worklog/personal.adoc[]

include::partial$worklog/education.adoc[]

include::partial$worklog/infrastructure.adoc[]

include::partial$worklog/quick-commands.adoc[]

include::partial$worklog/related.adoc[]

== Today's Remaining TODO

=== Must Do (Before End of Day)

=== Should Do (If Time Permits)

=== Stretch Goals

Header

Element Rule

Title

= WRKLOG-YYYY-MM-DD — exact date, no descriptive suffix

:description:

Day name (bold in Summary, plain here) + concise summary of day’s output

:revdate:

YYYY-MM-DD matching the filename

Summary Section

The Summary opens with Day Name. followed by a dense paragraph. Quantify where possible: file counts, line counts, key outcomes. This paragraph is the entry point for monthly rollups.

Section Includes

Section includes pull from partials/worklog/. Content is written directly into these partials daily:

Partial Purpose

urgent.adoc

Time-sensitive items, blockers, escalations

morning.adoc

Early-day tasks, triage, planning

work-chla.adoc

Work-specific (CHLA) tasks and accomplishments

personal.adoc

Personal projects and homelab work

education.adoc

Learning, certifications, study sessions

infrastructure.adoc

Infrastructure changes, deployments, maintenance

quick-commands.adoc

CLI patterns learned or commands worth remembering

related.adoc

Cross-references to case studies, sessions, or other worklogs

Session Accomplishments

Inline content (not a partial) documenting Claude Code sessions. Each session gets an === Title heading with bullet points covering scope, key actions, and quantified output.

TODO Section

Three tiers, each with checkbox items (* [ ] or * [x]):

  • Must Do — non-negotiable for the day

  • Should Do — valuable if time permits

  • Stretch Goals — aspirational, no guilt if deferred

Section Partials Location

All section partials live in:

docs/modules/ROOT/partials/worklog/

These files are rewritten daily. They contain section-level content (headings, lists, prose) that the worklog page pulls in via include::partial$worklog/<name>.adoc[]. Empty partials are valid — they produce no output in the rendered page.

Requirements

  1. Every workday MUST have a worklog created via make new-day.

  2. The :description: attribute MUST include the day name and a summary of the day’s work.

  3. Session Accomplishments MUST list every AI-assisted work session with scope and quantified output (files touched, lines written).

  4. The TODO section MUST use the three-tier structure: Must Do, Should Do, Stretch Goals.

  5. Uncompleted Must Do items MUST carry forward to the next worklog or be explicitly dropped with justification.

  6. Section partials MUST be rewritten daily — stale content from previous days is misleading.

  7. No :toc: attribute in any worklog file.

  8. No hardcoded IPs, hostnames, or credentials — use {attributes}.

  9. Build MUST be clean before committing: make 2>&1 | grep -E "WARN|ERROR".

Compliance

Check Method Pass Criterion

Worklog exists for workday

ls pages/YYYY/MM/WRKLOG-YYYY-MM-DD.adoc

File exists

Description includes day name

grep ':description:' WRKLOG-*.adoc

Day name present (Monday-Sunday)

Session accomplishments documented

Visual inspection of == Session Accomplishments section

At least one session entry per AI-assisted workday

TODO tiers present

grep -c '=== Must Do|=== Should Do|=== Stretch' WRKLOG-*.adoc

All three tiers present

Build clean

make 2>&1 | grep -E 'WARN|ERROR'

Zero output

No stale partials

Compare partial dates against worklog date

Partials reflect current day’s content

Sub-Partial Reusability — Four-Layer Architecture

The three-layer daily-notes architecture (worklog shell → daily-notes index → concern partials) handles topic separation. But some concern partials contain granular code blocks, command patterns, or technique documentation that will be reused on future days. These MUST be extracted into sub-partials.

The Pattern

When a concern partial contains two or more distinct, reusable blocks (commands, techniques, code patterns), create a subdirectory named after the parent partial and place each block in its own sub-partial:

Layer 3: partials/worklog/daily-notes/YYYY-MM-DD/topic-name.adoc          <-- concern partial (index)
Layer 4: partials/worklog/daily-notes/YYYY-MM-DD/topic-name/block-one.adoc <-- reusable sub-partial
Layer 4: partials/worklog/daily-notes/YYYY-MM-DD/topic-name/block-two.adoc <-- reusable sub-partial

Layer 3 — Concern Partial as Index

The concern partial becomes an index. It provides narrative framing — the why and when — then includes sub-partials for the how:

// Concern: Topic description
// Partial: partials/worklog/daily-notes/YYYY-MM-DD/topic-name.adoc

==== Topic Heading

Narrative context — what prompted this work, what problem it solves.

include::partial$worklog/daily-notes/YYYY-MM-DD/topic-name/technique-one.adoc[]

include::partial$worklog/daily-notes/YYYY-MM-DD/topic-name/technique-two.adoc[]

===== Summary or next steps

Layer 4 — Reusable Sub-Partials

Each sub-partial is self-contained: one technique, one command pattern, one code block. It MUST be independently includable — no dependency on the parent’s narrative:

// Reusable: Brief description of what this sub-partial teaches
// Parent: topic-name.adoc

===== Technique Heading

Explanation of the pattern.

.Example usage
[source,bash]
----
command --with real-arguments
----

.Breakdown
[cols="1,3"]
|===
| Element | What it does
| ...     | ...
|===

Rules

  1. Split trigger: A concern partial with 2+ distinct reusable blocks (different commands, different tools, different techniques) MUST use sub-partials. A single-block partial stays flat.

  2. Name by content: Sub-partials are named by what they teach (process-kill-batch.adoc, wifi-reconnect.adoc), not by sequence or meta-labels.

  3. Self-contained: Each sub-partial is independently includable. No forward references to siblings or dependency on the parent’s prose.

  4. Comment header: Every sub-partial opens with // Reusable: and // Parent: comments for discoverability.

  5. Linux contrast encouraged: When documenting Windows/PowerShell/vendor CLI patterns, include the Linux equivalent. The contrast is the teaching moment.

  6. Future inclusion: When a sub-partial is reused on a later day, include it directly — do not copy the content. The sub-partial is the single source of truth:

// In a future daily note:
include::partial$worklog/daily-notes/2026-06/2026-06-25/powershell-windows-sysadmin/process-kill-batch.adoc[]

Examples in Production

Date Topic Partial Sub-Partials

2026-06-24

mschapv2-to-cert-migration.adoc

overview.adoc, code-segmentation.adoc, project-inventory.adoc, api-toolkit.adoc, gpo-delta-analysis.adoc, cross-platform.adoc, render-build-view.adoc, commit-summary.adoc

2026-06-25

powershell-windows-sysadmin.adoc

process-kill-batch.adoc, wifi-reconnect.adoc

Compliance

Check Method Pass Criterion

Sub-partials exist when needed

Concern partial has 2+ distinct reusable blocks

Subdirectory exists with individual sub-partials

Sub-partials are self-contained

Each sub-partial renders independently

No broken references when included alone

Comment headers present

grep -r '// Reusable:' partials/worklog/daily-notes/

Every sub-partial has // Reusable: + // Parent: comments

No content duplication

Reused content is `include::’d, not copied

Single source of truth maintained

Related