phil/StarPunk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(tags): Add tag archive route and admin interface integration

Browse Source 
Implement Phase 3 of v1.3.0 tags feature per microformats-tags-design.md:

Routes (starpunk/routes/public.py):
- Add /tag/<tag> archive route with normalization and 404 handling
- Pre-load tags in index route for all notes
- Pre-load tags in note route for individual notes

Admin (starpunk/routes/admin.py):
- Parse comma-separated tag input in create route
- Parse tag input in update route
- Pre-load tags when displaying edit form
- Empty tag field removes all tags

Templates:
- Add tag input field to templates/admin/edit.html
- Add tag input field to templates/admin/new.html
- Use Jinja2 map filter to display existing tags

Implementation details:
- Tag URL parameter normalized to lowercase before lookup
- Tags pre-loaded using object.__setattr__ pattern (like media)
- parse_tag_input() handles trim, dedupe, normalization
- All existing tests pass (micropub categories, admin routes)

Per architect design:
- No pagination on tag archives (acceptable for v1.3.0)
- No autocomplete in admin (out of scope)
- Follows existing media loading patterns

Generated with Claude Code

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Phil Skentelbery
2025-12-10 11:42:16 -07:00
parent 377027e79a
commit 372064b116
41 changed files with 2573 additions and 10573 deletions
Download Patch File Download Diff File Expand all files Collapse all files

85
CLAUDE.md
View File

@@ -8,97 +8,50 @@ This file contains operational instructions for Claude agents working on this pr
- All Python commands must be run with `uv run` prefix
- Example: `uv run pytest`, `uv run flask run`
## Agent Protocol (All Agents)
**IMPORTANT**: All agents must review `docs/DOCUMENTATION.md` before starting work. This file is the authoritative source for documentation organization and supersedes any other instructions.
## Agent-Architect Protocol
When invoking the agent-architect, always remind it to:
1. Review documentation in docs/ before working on the task it is given
- docs/architecture, docs/decisions, docs/standards are of particular interest
1. Review `docs/DOCUMENTATION.md` for documentation organization standards
2. Give it the map of the documentation folder as described in the "Understanding the docs/ Structure" section below
2. Review documentation in docs/ before working on the task it is given
- docs/architecture, docs/decisions, docs/standards are of particular interest
3. Search for authoritative documentation for any web standard it is implementing on https://www.w3.org/
4. If it is reviewing a developers implementation report and it is accepts the completed work it should go back and update the project plan to reflect the completed work
4. If it is reviewing a developers implementation report and it accepts the completed work it should go back and update the project plan to reflect the completed work
## Agent-Developer Protocol
When invoking the agent-developer, always remind it to:
1. **Document work in reports**
- Create implementation reports in `docs/reports/`
- Include date in filename: `YYYY-MM-DD-description.md`
1. Review `docs/DOCUMENTATION.md` for documentation organization standards
2. **Update the changelog**
2. **Document work in design folder**
- Create implementation reports in `docs/design/{version}/`
- Include date in filename: `YYYY-MM-DD-description.md`
- All developer interaction (questions, responses, reports, reviews) goes in design/{version}/
3. **Update the changelog**
- Add entries to `CHANGELOG.md` for user-facing changes
- Follow existing format
3. **Version number management**
4. **Version number management**
- Increment version numbers according to `docs/standards/versioning-strategy.md`
- Update version in `starpunk/__init__.py`
4. **Follow git protocol**
5. **Follow git protocol**
- Adhere to git branching strategy in `docs/standards/git-branching-strategy.md`
- Create feature branches for non-trivial changes
- Write clear commit messages
## Documentation Navigation
## Documentation
### Understanding the docs/ Structure
The `docs/` folder is organized by document type and purpose:
- **`docs/architecture/`** - System design overviews, component diagrams, architectural patterns
- **`docs/decisions/`** - Architecture Decision Records (ADRs), numbered sequentially (ADR-001, ADR-002, etc.)
- **`docs/deployment/`** - Deployment guides, infrastructure setup, operations documentation
- **`docs/design/`** - Detailed design documents, feature specifications, phase plans
- **`docs/examples/`** - Example implementations, code samples, usage patterns
- **`docs/migration/`** - Migration guides for upgrading between versions and configuration changes
- **`docs/projectplan/`** - Project roadmaps, implementation plans, feature scope definitions
- **`docs/releases/`** - Release-specific documentation, release notes, version information
- **`docs/reports/`** - Implementation reports from developers (dated: YYYY-MM-DD-description.md)
- **`docs/reviews/`** - Architectural reviews, design critiques, retrospectives
- **`docs/security/`** - Security-related documentation, vulnerability analyses, best practices
- **`docs/standards/`** - Coding standards, conventions, processes, workflows
### Where to Find Documentation
- **Before implementing a feature**: Check `docs/decisions/` for relevant ADRs and `docs/design/` for specifications
- **Understanding system architecture**: Start with `docs/architecture/overview.md`
- **Coding guidelines**: See `docs/standards/` for language-specific standards and best practices
- **Past implementation context**: Review `docs/reports/` for similar work (sorted by date)
- **Project roadmap and scope**: Refer to `docs/projectplan/`
### Where to Create New Documentation
**Create an ADR (`docs/decisions/`)** when:
- Making architectural decisions that affect system design
- Choosing between competing technical approaches
- Establishing patterns that others should follow
- Format: `ADR-NNN-brief-title.md` (find next number sequentially)
**Create a design doc (`docs/design/`)** when:
- Planning a complex feature implementation
- Detailing technical specifications
- Documenting multi-phase development plans
**Create an implementation report (`docs/reports/`)** when:
- Completing significant development work
- Documenting implementation details for architect review
- Format: `YYYY-MM-DD-brief-description.md`
**Update standards (`docs/standards/`)** when:
- Establishing new coding conventions
- Documenting processes or workflows
- Creating checklists or guidelines
### Key Documentation References
- **Architecture**: See `docs/architecture/overview.md`
- **Implementation Plan**: See `docs/projectplan/v1/implementation-plan.md`
- **Feature Scope**: See `docs/projectplan/v1/feature-scope.md`
- **Coding Standards**: See `docs/standards/python-coding-standards.md`
- **Testing**: See `docs/standards/testing-checklist.md`
See `docs/DOCUMENTATION.md` for the authoritative documentation structure, navigation guidance, and key references.
## Project Philosophy