git-captains-log 0.7.1__tar.gz → 0.7.2__tar.gz

{git_captains_log-0.7.1 → git_captains_log-0.7.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: git-captains-log
-Version: 0.7.1
+Version: 0.7.2
 Summary: Automatically aggregate git commit messages daily into markdown logs
 Author: Captain's Log Team
 License-File: LICENSE

git_captains_log-0.7.2/docs/README.md

@@ -0,0 +1,34 @@
+# Documentation Map
+
+This repository uses a docs-as-code layout bootstrapped by [adrlane](https://github.com/koradon/adrlane).
+
+## Structure
+
+| Path | Purpose |
+| --- | --- |
+| `docs/specs/` | Feature specifications, behavior, and contracts |
+| `docs/plans/` | Implementation plans derived from specs |
+| `docs/adr/` | Architecture and design decision records |
+| `docs/ideas/` | Early concepts that may be promoted to specs |
+| `docs/roadmap/` | Now / Next / Later horizons for future initiatives |
+| `docs/llm/` | Agent-facing documentation contract and templates |
+
+## How this documentation grows
+
+`adrlane init` creates a minimal core and does not predict future project shape.
+
+When the project gains a new, recurring documentation need (for example CLI reference, runbooks, or API reference), the agent should:
+
+1. Add a new top-level folder under `docs/` when the content does not fit `specs/`, `plans/`, `adr/`, `ideas/`, or `roadmap/`.
+2. Copy a starter template from `docs/llm/templates/` and adapt it.
+3. Update this file to document the new section.
+
+Do not create empty folders "for later". Grow the tree only when there is real content to place there.
+
+Release history lives in Git and release tooling, not in `docs/`.
+
+For the full growth model, see the [adrlane documentation model](https://github.com/koradon/adrlane#documentation-model).
+
+## For agents
+
+Read `docs/llm/AGENT_PROTOCOL.md` first. It defines the doc workflow (`idea -> spec -> plan`) and how to extend the documentation consistently.

git_captains_log-0.7.2/docs/ideas/README.md

@@ -0,0 +1,24 @@
+# Ideas
+
+Ideas are early, uncommitted concepts. The goal is to decide whether a concept deserves further investment.
+
+An idea can flow into:
+
+- a **Spec** (`docs/specs/`) when the desired behavior and contracts become clear
+- a **Plan** (`docs/plans/`) when implementation needs multiple steps or sessions
+
+If an idea does not pass evaluation, the agent may set `## Status` to `rejected` (and optionally link what was decided instead).
+
+## Common flow
+
+1. Create/update an idea in `docs/ideas/`.
+2. When the behavior is clear enough, create a spec in `docs/specs/` and link them in `## Related`.
+3. When implementation is non-trivial, create a plan in `docs/plans/` and link it from the spec.
+
+## Template
+
+Copy and adapt `docs/llm/templates/idea.md`.
+
+## How to stay agnostic
+
+Ideas describe outcomes and constraints without assuming a specific stack (web, backend, CLI, or binaries).

git_captains_log-0.7.2/docs/roadmap/README.md

@@ -0,0 +1,15 @@
+# Roadmap (Now / Next / Later)
+
+The roadmap holds future initiatives without committing to exact dates.
+
+- **Now**: active work or work starting soon (high confidence)
+- **Next**: upcoming work with high confidence, but not started yet
+- **Later**: speculative bets or ideas pending further validation
+
+### Update semantics
+
+- Add items when there is enough clarity to evaluate them.
+- Link roadmap items to the related **Idea**, **Spec**, and/or **Plan** documents.
+- Move items between horizons when confidence changes.
+
+If the project needs more detailed horizon pages, the agent can add them under `docs/roadmap/` using `docs/llm/templates/roadmap.md`.

{git_captains_log-0.7.1 → git_captains_log-0.7.2}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "git-captains-log"
-version = "0.7.1"
+version = "0.7.2"
 # dynamic = ["version"]  # Temporarily disabled for release
 description = "Automatically aggregate git commit messages daily into markdown logs"
 authors = [
@@ -36,8 +36,6 @@ packages = ["src"]
 [tool.hatch.build.targets.sdist]
 include = [
     "src/",
-    "commit-msg",
-    "commit-msg-package",
     "README.md",
     "LICENSE",
 ]

{git_captains_log-0.7.1 → git_captains_log-0.7.2}/src/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '0.7.1'
-__version_tuple__ = version_tuple = (0, 7, 1)
+__version__ = version = '0.7.2'
+__version_tuple__ = version_tuple = (0, 7, 2)
 
 __commit_id__ = commit_id = None

{git_captains_log-0.7.1 → git_captains_log-0.7.2}/src/cli.py

@@ -75,17 +75,12 @@ def setup():
     # Install commit-msg hook
     print("Installing Git commit-msg hook...")
 
-    # Look for commit-msg-package (for package installations) first
-    commit_msg_source = package_dir.parent / "commit-msg-package"
+    # Hook templates ship inside the package (src/hooks/), so this works the
+    # same way for an editable/source install and a real wheel install.
+    hooks_dir = package_dir / "hooks"
+    commit_msg_source = hooks_dir / "commit-msg-package"
     if not commit_msg_source.exists():
-        # Fall back to regular commit-msg (for installation script)
-        commit_msg_source = package_dir.parent / "commit-msg"
-    if not commit_msg_source.exists():
-        # Try alternate location (when installed from wheel)
-        commit_msg_source = Path(__file__).parent.parent / "commit-msg-package"
-    if not commit_msg_source.exists():
-        # Final fallback
-        commit_msg_source = Path(__file__).parent.parent / "commit-msg"
+        commit_msg_source = hooks_dir / "commit-msg"
 
     commit_msg_dest = git_hooks_dir / "commit-msg"
     if commit_msg_source.exists():