steplog 0.10.0__tar.gz

steplog-0.10.0/.gitignore

@@ -0,0 +1,36 @@
+.DS_Store
+__pycache__/
+*.pyc
+
+# Claude Code's local working directory — may contain session transcripts,
+# settings.local.json (per-user permission grants), and other transient
+# state. Default: ignore everything in .claude/, then re-include the
+# project-shared settings.json so the Stop hook config ships with the repo.
+.claude/*
+!.claude/settings.json
+
+# Reference material that lives in the repo but is not part of the project.
+z-archive reference files/
+
+# Steplog migration snapshots — local recovery points, per-clone safety
+# net. The audit trail (MIGRATIONS.md) is what's shared in git; the
+# actual snapshots stay on the operator's machine.
+.steplog/backups/
+
+# Feature-008 s_063: STATUS narrative patch scaffolds. Transient
+# operator/agent workflow artifacts under .steplog/patches/<timestamp>.json
+# generated by `steplog narrative --propose`. The applied state.json
+# change is what's shared in git; the scaffold files stay local.
+.steplog/patches/
+
+# Feature-016 Phase 1 / s_066 (a_160): operator's editable-install venv.
+# `pip install -e .` from the source clone creates this; the install is
+# per-machine dogfood state, not shared in git.
+.venv/
+
+# Feature-016 Phase 2 / s_067 (a_163): wheel-build artifacts. `python -m
+# build` produces dist/steplog-X.Y.Z-py3-none-any.whl + sdist.tar.gz here;
+# `build/` is hatchling's intermediate scratch. Both regenerate from
+# pyproject.toml + sources, so they don't belong in git.
+dist/
+build/

steplog-0.10.0/AGENTS.md

@@ -0,0 +1,44 @@
+# Steplog (this project)
+
+This project is governed by Steplog itself. Before doing anything else this
+session, read AGENT_PROTOCOL.md at the repo root and follow it for the
+whole session. The canonical state lives at .steplog/state.json. Validate
+against state.schema.json after every write.
+
+The canonical PRD is PRD/Steplog-PRD-v4.1.html. When in doubt about scope,
+that wins. Feature-level specs live alongside it (PRD/feature-NNN-prd.md).
+Operator-facing docs (getting-started, design brief) live in docs/.
+
+After any meaningful work, run (preferred — works after `pip install -e .`):
+    steplog show
+or, from a source clone without the editable install:
+    python3 -m steplog.gen .steplog/state.json state.schema.json > BUILD_LOG.html
+
+## Attribution and commit metadata
+
+Operator policy: no AI-agent attribution in commits, source files, or
+rendered output. Per-activity agent attribution lives in
+`.steplog/state.json` via the `agent_id` field. The full rule (do-not
+list and exceptions) is in AGENT_PROTOCOL.md → "Attribution and commit
+metadata".
+
+## Local preview server quirks
+
+When a session needs to live-test BUILD_LOG.html in a browser (e.g. clicking
+a chip to verify drawer wiring), launch the HTTP server through `/bin/sh -c`
+rather than calling `python3 -m http.server` directly via the IDE preview
+button. Claude.app's `disclaimer` helper sits between the preview launcher
+and the spawned process and can block the socket bind silently — the process
+starts, the preview tool reports success, but `lsof -i :PORT` shows nothing
+listening and `curl` returns connection refused. Wrapping in `/bin/sh -c
+'exec /opt/homebrew/bin/python3.13 -m http.server "$PORT" --directory ...'`
+threads through the helper cleanly. Discovered during Session 1a's drawer-
+wiring smoke test (a_069 has the diagnosis trail).
+
+For DOM click tests, prefer `chip.click()` (the standard `HTMLElement.click()`
+method) inside `mcp__Claude_Preview__preview_eval` rather than the
+`mcp__Claude_Preview__preview_click` tool. `preview_click` does not reliably
+trigger document-level delegated event listeners (which Steplog's drawer
+dispatch relies on at `src/steplog/gen.py` — the dispatcher; line numbers
+shift with edits, grep for `data-drawer` to find it); `chip.click()` does.
+Surfaced during Session 1b smoke tests (a_073).

steplog-0.10.0/AGENT_PROTOCOL.md

@@ -0,0 +1,489 @@
+# AGENT_PROTOCOL.md
+
+## Attribution and commit metadata
+
+The operator is the author of every commit on this project. Per-activity 
+agent attribution is captured in `.steplog/state.json` via the `agent_id` 
+field — that is the canonical record of which agent (claude-code, 
+claude-desktop, codex, cursor, human, etc.) produced each activity. 
+Commit metadata does not duplicate that signal.
+
+Do NOT add to commit messages:
+- `Co-Authored-By: Claude` or any AI-agent co-author trailer
+- `Generated with Claude Code` or similar provenance tags
+- Any signature block naming an AI agent
+
+Do NOT add to source files, documentation, or rendered output:
+- Comments stating "generated by an AI" or naming an AI tool
+- Header blocks crediting an AI agent
+- "Powered by" or similar markers in HTML / CSS / JS
+- Attribution stamps in PRD documents or markdown files
+
+Exceptions (preserve attribution as-is):
+- Third-party vendor headers in auto-generated SDK files
+- License notices required by upstream open-source dependencies
+- Operator-authored/directed attribution the operator has explicitly written or asked for
+
+If you (an agent) are uncertain whether a specific surface counts as 
+covered by this rule, ask before writing.
+
+## Project Context
+
+You are working on a project that uses the Steplog build governance convention.
+A canonical state file lives at `.steplog/state.json`. It is the project plan-of-record
+and the build journal. You read it at session start and update it as you work — across
+all stages of the work, not just at the shipped end.
+
+> **For agents:** This file is the protocol. Most agents discover it via
+> `AGENTS.md` at the repo root (or via `CLAUDE.md`, which is now a one-line
+> pointer to AGENTS.md). Whichever doorway you came through, read this protocol
+> in full before doing anything else this session — including before you
+> read the canonical PRD or any feature PRD. Other agents on this project
+> (Claude Code, Codex CLI, Cursor, Aider, etc.) follow the same rules; the
+> goal is that any of them can pick up where the last one left off.
+
+## Session start ritual
+
+1. Read `.steplog/state.json`
+2. Identify all activities with `status="in_progress"` and the top of `next_actions[]`
+3. Note which `spec_sections` are mid-lifecycle (any stage `in_progress`)
+4. Propose to the user which item(s) to tackle this session
+5. Confirm before starting. Do not silently pick.
+
+## PRD Import ritual (only when starting a new project)
+
+Run this once when bootstrapping Steplog onto a project that already has a
+PRD but does not yet have `spec_sections` populated. Do not run on an
+ongoing project — `spec_sections` is append-only by convention; reshaping
+existing sections wholesale is a separate, hand-edited task.
+
+The ritual:
+
+1. The operator names the PRD (e.g. `PRD/your-prd.md`, `docs/spec.html`,
+   any format you can read).
+2. **Read the PRD in full.** Do not skim. The translation from PRD → sections
+   is a judgement call the operator will check, so you need to understand
+   the document's structure and intent.
+3. Propose a list of sections. Each must include:
+   - `id` (next free `s_NNN`),
+   - `ref` (a pointer to the relevant PRD section, e.g. `your-prd.md §3`),
+   - `title` (short),
+   - `category` (one of: `core`, `security`, `enhancement`, `infrastructure`,
+     `research`, `compliance`),
+   - `intent_summary` (technical, ≤200 chars),
+   - `plain_summary` (plain language, second person, ≤200 chars, no jargon),
+   - `lifecycle` with all five stages set to `not_started`/`planned`/etc.
+   - `depends_on` and `prd_anchor` are optional but preferred.
+4. Output the proposal as a Steplog-native JSON patch:
+   ```json
+   {
+     "version": "0.6.0",
+     "ops": [
+       { "op": "add_sections", "sections": [ ... ] }
+     ]
+   }
+   ```
+5. Save the patch to a file (e.g. `/tmp/prd-import.json`) and tell the
+   operator how to apply it:
+   ```
+   steplog apply-patch /tmp/prd-import.json
+   ```
+   That dry-runs by default and prints the diff. The operator reviews and
+   either applies (`--apply`) or edits the JSON first.
+
+You never write to state.json directly during PRD import. The operator
+reviews every section before applying. If they reject any, edit the JSON
+file and re-run the dry-run.
+
+A sample patch lives at `docs/patches/example-prd-import.json` for reference.
+
+## PRD Review ritual (before any build work on a feature PRD)
+
+Steplog has four drift-prevention layers. Three are automated and fire
+on commits, turn-ends, or generator runs (the pre-commit hook, the
+Stop hook, the drift detector). The fourth is this ritual: **a
+structured review of the PRD itself before any build code is
+committed**, run by the agent and reviewed by the operator. It catches
+the class of drift the other three cannot see — a PRD that asserts
+something about the repo that is not actually true.
+
+History: introduced after the feature-006 review found a missing
+mockup file, and again after Session 1a hit an `archive/` directory
+the PRD assumed was tracked but was actually a personal-scratch
+convention. Both were caught only because someone happened to look.
+This ritual makes the looking systematic.
+
+### When the ritual fires
+
+Fire the ritual when an operator asks you to begin build work on a
+feature PRD — phrases like "implement this PRD," "start session N
+of feature-X," "go," or any direct invocation of work on a feature
+spec. Run it **before** any code or any modification of state.json
+for that feature.
+
+Also fire when an operator asks for a "review" of a PRD, or when
+you encounter a PRD you have not previously verified during a
+multi-session feature implementation.
+
+Do **not** fire when reading a PRD for context only, when extending
+or revising a PRD, or during normal feature-build sessions on
+already-reviewed PRDs.
+
+### The five-category checklist
+
+Address every item in every category. Produce the structured output
+described below, even when nothing fails.
+
+**1. File and path verification (mechanical)**
+- Does every file path the PRD references exist in the repo, or is
+  it explicitly marked as new?
+- Do referenced directories exist? (Including: do any have hidden
+  trailing whitespace, or are they untracked when assumed tracked?)
+- Are documentation paths correct (e.g., `docs/getting-started.html`,
+  not `getting-started.html`)?
+- Are referenced visual sources (mockups, screenshots, sketches)
+  actually present in the repo?
+
+**2. Schema and version consistency (mechanical)**
+- Do schema version bumps cited in the PRD match the actual current
+  schema version in `state.schema.json`?
+- Do migration numbers proposed not conflict with existing migrations
+  in `src/steplog/migrations/`?
+- Do field names match what is actually in the schema (`steplog_version`
+  vs `schema_version`, `archived_at` vs `archived`, etc.)?
+- Do activity kinds, section categories, lifecycle stages, nudge tag
+  names referenced exist in the current schema, or are they explicitly
+  added by this PRD?
+
+**3. Section and activity references (mechanical)**
+- Do proposed section IDs not collide with already-allocated IDs in
+  `state.json.spec_sections[]`?
+- Do references to existing sections point to sections that actually
+  exist?
+- Do cross-references to other PRDs use canonical paths that match
+  the repo?
+
+**4. Convention and history checks (judgment — the keystone)**
+- **Does this PRD assume the repo is in a state it isn't actually
+  in?** Common sub-cases: gitignored vs tracked, file moved but not
+  committed, hook installed but not symlinked, directory exists but
+  is empty, file present but at unexpected path, directory name with
+  hidden whitespace.
+- **Does this PRD overwrite or conflict with operator decisions from
+  earlier features?** Read git history if uncertain. Was a directory
+  or convention created with deliberate intent that this PRD would
+  silently overturn?
+- **Is the agent making assumptions about operator intent that the
+  operator should confirm?** When an existing convention contradicts
+  the PRD's assumption, the question to surface is not "which is
+  right" but "did the operator intend the convention or not?"
+- **Are there project-history considerations the PRD's author may
+  not have known about?** Old artifacts, scratch folders, prior
+  aborted features, decisions reflected in `MIGRATIONS.md`.
+
+This category cannot be automated. It is the keystone of the ritual
+and is permanently the agent's and operator's job.
+
+**5. Terminology and tone (judgment)**
+- Do operator-facing strings match the tone established in
+  `docs/steplog-design-brief.html` and `docs/getting-started.html`?
+- Are both technical and plain registers present where required?
+- Does the PRD use Steplog's canonical terminology consistently
+  ("sections" not "milestones", "activities" not "tasks", etc.)?
+
+### Output format
+
+Produce a Markdown review document at `PRD/feature-NNN-prd-review.md`
+containing:
+
+1. **Header.** PRD title, date, reviewer (your `agent_id`), repo
+   state (branch, commit, schema version).
+2. **Six numbered sections.** One per axis:
+   factual claims, design conflicts with existing features, cross-PRD
+   conflicts, open questions, counter-proposals, per-session risk
+   ranking. (The five-category checklist informs sections 1–3 and
+   parts of 5; sections 2/3/4/5/6 add the cross-cutting axes.)
+3. **Each finding has both registers.** Technical description
+   (what file/line/field) and plain description (what it means and
+   why it matters).
+4. **Counter-proposals are concrete.** When you find a problem,
+   propose specific PRD-language replacements ready to drop in.
+5. **Executive verdict.** One of three:
+   - **APPROVE** — no failures, no judgment items; build can begin.
+   - **APPROVE WITH REVISIONS** — failures present; path forward is
+     clear; PRD is revised, then build proceeds.
+   - **BLOCK** — failures present and the path forward is not clear;
+     the operator must adjudicate before any further action.
+6. **Action list** — flat list of recommendations the operator
+   should action.
+
+The recommendation is yours; the decision is the operator's. Do not
+proceed with build work until the operator approves a path forward.
+
+### Exit conditions
+
+Log the review as a `review` activity in `state.json`, with `tags`
+including `prd-review` and the PRD's feature label (e.g.
+`feature-009`). The activity's `summary` carries the technical
+register; `plain_description` carries the plain register. Both old
+and new content of any counter-proposed PRD passages can live in
+`summary` for the audit trail.
+
+A migration is **not** added — the existing `review` activity kind
+covers the use case. A more specific `prd_review` kind may be
+introduced later; for now, filter by `kind=review AND tags includes
+'prd-review'`.
+
+## Activity kinds — what to log, and when
+
+Every meaningful unit of work is an activity. Pick the right kind:
+
+| kind              | when to use                                                       |
+| ----------------- | ----------------------------------------------------------------- |
+| `spec_draft`      | You authored a new PRD section or major sub-section               |
+| `spec_revision`   | You edited an existing section in a way that changes scope        |
+| `design_decision` | You picked an architecture, schema, UX, or stack approach         |
+| `exploration`     | You ran a research spike or prototype that did not ship           |
+| `build_step`      | You completed a meaningful unit of implementation                 |
+| `test_result`     | A test pass or fail worth recording                               |
+| `bug_fix`         | You identified and resolved a defect                              |
+| `review`          | You completed a code, spec, or design review                      |
+| `ship_event`      | You deployed, released, or flagged something on                   |
+| `note`            | Anything else worth recording for future context                  |
+
+Threshold: *"would a future agent need this to understand the project?"*
+Do NOT log every commit, every file edit, or every tool call.
+
+## How to log an activity
+
+1. Read `.steplog/state.json`
+2. Append to `activities[]` with an incremented id (`a_001`, `a_002`, ...)
+3. Set `kind`, `status`, and `spec_section` (link to the `s_NNN` it advances)
+4. Set `status="in_progress"` when starting, `"done"` when finished
+5. Always include: `id`, `kind`, `status`, `title`, `agent` (your label)
+6. Include `artifacts` when they exist: commit SHAs, file paths, URLs
+7. If a `design_decision`, also append to `decisions[]` and set `decision_id`
+
+## Advancing the lifecycle
+
+Each `spec_section` has a lifecycle map: `spec`, `design`, `build`, `ship`,
+and (from 0.6.0) `prod`. When you complete an activity that finishes a
+stage for a section, update that section's lifecycle entry from
+`in_progress` to `done`. Move the next stage from `not_started` to
+`planned` (or `in_progress` if you start it).
+
+### Invariant: stable sections have no in-flight stages
+
+When `section.status == "stable"`, every lifecycle stage on that section
+must be either `done` or `not_started`. A `stable` section with any stage
+at `planned` or `in_progress` is a contradiction — either the work isn't
+actually done, or the lifecycle entry is stale and needs to be advanced.
+
+The renderer enforces this via the `lifecycle_stuck_under_stable` nudge
+rule (see state.schema.json `x-nudge-rules`): on every render, sections
+that violate the invariant surface as a yellow nudge card with the list
+of affected sections. Either advance the stage to `done`, drop the
+section's `status` back to `drafting` until the stage lands, or — for a
+documented deferral on a polish item — mark the nudge as reviewed and
+note the parked work in `intent_summary`.
+
+This rule was added the first time the operator caught the BUILD MAP
+showing stale ship-stage entries on settled sections (2026-05-09). The
+fix isn't to clean up by hand each time; it's to surface the drift on
+every render so it can't accumulate silently.
+
+## Maintaining the forward queue
+
+`next_actions[]` is not optional. It is how the next session knows where to start.
+
+- When you finish an activity, prune any `next_actions[]` items it satisfied
+- When you discover work that should happen later, append to `next_actions[]`
+- At session end, ensure `next_actions[]` has at least 3 items so the next session
+  opens with a queue, not a blank page
+
+## Proactive STATUS narrative updates
+
+The top of the dashboard is the STATUS module: four short prose blocks
+(`headline`, `just_shipped`, `in_progress`, `up_next`) stored at the
+top-level `narrative` key in `.steplog/state.json`. They are the
+operator's plain-English summary of where the project is — written for a
+human glance, not for downstream tooling. Section lifecycle and
+activities are what's *factually* true; the narrative is what the
+operator *says* about it.
+
+### When to propose an update
+
+At end-of-session, if any of the following landed during the session,
+propose a narrative update before you hand off:
+
+- A `ship_event` activity (a section just moved through `lifecycle.ship = done`)
+- A `prod_event` activity (a section just moved through `lifecycle.prod = done`)
+- A `test_result` or `spec_revision` activity tagged as a milestone
+  (operator-judged — when in doubt, ask)
+- A `design_decision` that meaningfully reframes what the project is doing
+
+The narrative must stay synchronized with the underlying state. If the
+last shipped section in `just_shipped` no longer matches what `lifecycle`
+shows, the narrative is stale and the dashboard will surface a
+`narrative_stale` nudge.
+
+### How to propose
+
+Use the CLI scaffold rather than hand-editing `narrative` in
+`state.json`:
+
+```bash
+steplog narrative --propose \
+    --blocks just_shipped,in_progress,up_next \
+    --by claude-code
+```
+
+This writes a patch scaffold to `.steplog/patches/narrative-<timestamp>.json`
+containing `set_narrative_block` ops with placeholder text plus a
+companion `add_activity` op (kind=`narrative_update`). Edit the
+placeholder text in the scaffold, then dry-run + apply via
+`steplog apply-patch`. The Claude Code plugin exposes this same flow as
+`/steplog-narrative`.
+
+### Approval rule
+
+**The operator approves narrative content before it lands.** Steplog is
+capture-not-brain: agents do not write project-level prose unilaterally.
+Propose the scaffold, show the operator the proposed text + rationale,
+and apply only after explicit approval. The one documented exception is
+a session that has a pre-authorized autonomous run — and even then, the
+operator's next QA pass functions as retroactive content review, and the
+proposal+rationale must still be captured in the `narrative_update`
+activity summary.
+
+### What good narrative looks like
+
+- **headline** (≤140 chars): one sentence on the project's current state
+- **just_shipped** (≤300 chars): what landed recently, plain-English
+- **in_progress** (≤300 chars): what's actively being worked on right now
+- **up_next** (≤300 chars): the next 1–3 things on deck
+
+Plain-English, no internal section IDs in the prose itself (those are
+already linked elsewhere), no version numbers unless they're
+operator-facing. Write for a non-expert collaborator catching up after a
+week away.
+
+## Tags that trigger nudges
+
+When you tag an activity with any of `[auth, secret, pii, payment, db, migration, deploy]`,
+the system surfaces a question to the user. Add the tag honestly. Do not omit tags
+to avoid the prompt.
+
+## Security inventory
+
+`.steplog/state.json` includes a top-level `security_inventory` object that catalogues
+the project's security-relevant assets. Hand-curated by the agent and the operator as
+the project evolves — not auto-detected. It pairs with the tag-trigger nudges above:
+tags surface the *event*; the inventory tracks the *state of the world*. The renderer
+surfaces both in BUILD_LOG.html.
+
+### The four buckets
+
+| bucket          | what goes in                                                                         |
+| --------------- | ------------------------------------------------------------------------------------ |
+| `env_vars`      | Environment variables the project relies on (names + where, never values)            |
+| `secrets`       | Named credentials, API keys, signing keys (referenced by vault path / URL, never stored) |
+| `hook_scripts`  | Versioned hooks (git, Claude Code, etc.) — anything that runs automatically          |
+| `settings`      | Config files that affect security posture: Claude Code config, sensitive `.gitignore` patterns |
+
+Empty buckets are fine. Omit a bucket when it has no entries.
+
+### Entry shape
+
+Every entry conforms to `$defs/security_entry`:
+
+```json
+{
+  "id":          "env_001",                       // required, pattern (env|sec|hk|set)_NNN
+  "name":        "STRIPE_KEY",                    // required, human label
+  "kind":        "api_key",                       // optional sub-classifier
+  "description": "Production Stripe API key.",    // optional, 1–2 sentences
+  "severity":    "high",                          // low | medium | high
+  "ref":         "1password://vault/stripe-prod", // path / URL / vault ref — NEVER the value
+  "rotated_at":  "2026-04-15T00:00:00Z",          // optional, surfaces stale entries later
+  "added_at":    "2026-05-08T00:00:00Z"
+}
+```
+
+### ID conventions
+
+IDs are bucket-prefixed and zero-padded. Stable once assigned.
+
+| prefix  | bucket          |
+| ------- | --------------- |
+| `env_`  | `env_vars`      |
+| `sec_`  | `secrets`       |
+| `hk_`   | `hook_scripts`  |
+| `set_`  | `settings`      |
+
+Numbering is per-bucket. `env_001`, `env_002`, ...; `sec_001`, `sec_002`, ...; etc.
+
+### When to add an entry
+
+Threshold: *would losing track of this surface a security risk?*
+
+Add when:
+
+- A new env var or secret enters the project's runtime
+- You introduce a hook (git or Claude Code) that runs automatically
+- You add a config file that affects what crosses trust boundaries
+- You add a `.gitignore` pattern that exists *to prevent secret leakage* (e.g., `*.env`, `*.pem`, `secrets/`)
+
+Do NOT add entries for: code files (already tracked by git), generic config with no
+security implication, build artifacts, or transient files.
+
+### Severity heuristics
+
+| severity   | when to use                                                                            |
+| ---------- | -------------------------------------------------------------------------------------- |
+| `low`      | Informational — local enforcement scripts, gitignore patterns, dev-only config         |
+| `medium`   | Review periodically — tokens with limited blast radius, internal services              |
+| `high`     | Touches production secrets, payment data, real user PII, or production auth            |
+
+When in doubt, start at `low` and raise as the surface grows.
+
+### Linking sections to inventory entries
+
+`spec_sections[]` items can include an optional `security.uses` array referencing entry IDs:
+
+```json
+{
+  "id": "s_004",
+  "title": "Pre-commit hook",
+  "security": { "uses": ["hk_001"] }
+}
+```
+
+This drives the BUILD_LOG.html "X sections touch sensitive surface" strap and lets readers
+see which sections of the project touch which security assets.
+
+### Inventory rules of thumb
+
+- Never store secret *values* in `state.json` — only references
+- Update `rotated_at` when you rotate a credential
+- Prune entries when an asset is permanently retired; do not silently leave dead entries
+
+## What you must NEVER do
+
+- Edit existing activity entries except to update `status`, `completed_at`, or `artifacts`
+- Delete decisions, `nudges_log` entries, or historical activities
+- Make judgments about whether the user's code or design is "good" or "secure" in the
+  log itself. Capture facts. Let the user decide.
+- Store secret values in `security_inventory` entries. Only references (paths, vault URLs,
+  env file locations) — never the secret itself.
+
+## Before you commit
+
+Run:
+
+```
+steplog show
+```
+(equivalent: `python3 -m steplog.gen .steplog/state.json state.schema.json > BUILD_LOG.html`)
+
+The pre-commit hook will block the commit if `state.json` was not updated since the last commit.

steplog-0.10.0/Assets/Logo/README.md

@@ -0,0 +1,18 @@
+# Steplog Signal Steps Logo
+
+Selected direction: **Signal Steps**.
+
+Files:
+
+- `steplog-signal-steps-lockup.svg` - primary full lockup for light backgrounds.
+- `steplog-signal-steps-icon.svg` - app icon / favicon / compact mark.
+- `steplog-signal-steps-dark-lockup.svg` - lockup on a dark badge.
+- `steplog-signal-steps-mono.svg` - monochrome-safe icon.
+
+Palette:
+
+- Ink: `#111318`
+- Green: `#22C55E`
+- Blue: `#38BDF8`
+- Amber: `#F59E0B`
+- Slate: `#64748B`

steplog-0.10.0/CLAUDE.md

@@ -0,0 +1,8 @@
+# CLAUDE.md → see AGENTS.md
+
+Steplog uses [AGENTS.md](AGENTS.md) as its canonical agent-instruction
+file. This stub exists only so Claude Code's auto-discovery convention
+still finds something at `CLAUDE.md`.
+
+If you're an agent reading this: read AGENTS.md (and AGENT_PROTOCOL.md
+at the repo root) before doing anything else this session.

steplog-0.10.0/PKG-INFO

@@ -0,0 +1,20 @@
+Metadata-Version: 2.4
+Name: steplog
+Version: 0.10.0
+Summary: Build governance for AI-assisted projects — state.json + plain-English dashboard.
+Author: Steplog
+License: MIT
+Keywords: agent-protocol,build-log,governance,steplog
+Requires-Python: >=3.9
+Requires-Dist: jsonschema>=4.0
+Description-Content-Type: text/markdown
+
+<img src="Assets/Logo/steplog-signal-steps-icon.svg" alt="Steplog" width="32" height="32" align="left" style="margin-right: 8px;">
+
+# Steplog
+
+Build governance for solo agentic builders. Capture/nudge, not brain. Cross-agent portable.
+
+The Claude Code plugin lives at [`plugins/claude-code/`](./plugins/claude-code) — start with [its README](./plugins/claude-code/README.md) if you're installing.
+
+For the design philosophy, read [`docs/steplog-design-brief.html`](./docs/steplog-design-brief.html). For the operator's getting-started guide, [`docs/getting-started.html`](./docs/getting-started.html).

steplog-0.10.0/README.md

@@ -0,0 +1,9 @@
+<img src="Assets/Logo/steplog-signal-steps-icon.svg" alt="Steplog" width="32" height="32" align="left" style="margin-right: 8px;">
+
+# Steplog
+
+Build governance for solo agentic builders. Capture/nudge, not brain. Cross-agent portable.
+
+The Claude Code plugin lives at [`plugins/claude-code/`](./plugins/claude-code) — start with [its README](./plugins/claude-code/README.md) if you're installing.
+
+For the design philosophy, read [`docs/steplog-design-brief.html`](./docs/steplog-design-brief.html). For the operator's getting-started guide, [`docs/getting-started.html`](./docs/getting-started.html).

steplog-0.10.0/archive/README.md

@@ -0,0 +1 @@
+archive/ holds v1 backups of Steplog's tracked documentation. When a doc gets a v2 revision, the v1 lands here. Personal reference materials live elsewhere; this directory is for project artifacts only.