When using pattern files with variables but no stdin input, ensure proper
template processing by initializing an empty message. This allows patterns
like:
./fabric -p pattern.txt -v=name:value
to work without requiring stdin input, while maintaining compatibility
with existing stdin usage:
echo "input" | ./fabric -p pattern.txt -v=name:value
Changes:
- Add empty message initialization in BuildSession when Message is nil
- Remove redundant template processing of message content
- Let pattern processing handle all template resolution
This simplifies the template processing flow while supporting both
stdin and non-stdin use cases.
- Successfully implemented path-based registry storage
- Moved to storing paths instead of full configurations
- Implemented proper hash verification for both configs and executables
- Registry format now clean and minimal.
File-Based Output Implementation
- Successfully implemented file-based output handling
- Demonstrated clean interface requiring only path output
- Properly handles cleanup of temporary files
- Verified working with both local and remote operations
Process template variables ({{var}}) consistently in both pattern files
and raw input messages. Previously variables were only processed when
using pattern files.
- Add template variable processing for raw input in BuildSession
- Initialize messageContent explicitly
- Remove errantly committed build artifact (fabric binary in previous commit)
Add initial set of utility plugins for the template system:
- datetime: Date/time formatting and manipulation
- fetch: HTTP content retrieval and processing
- file: File system operations and content handling
- sys: System information and environment access
- text: String manipulation and formatting operations
Each plugin includes:
- Implementation with comprehensive test coverage
- Markdown documentation of capabilities
- Integration with template package
This builds on the template system to provide practical utility functions
while maintaining a focused scope for the initial plugin release.
- Add new template package to handle variable substitution with {{variable}} syntax
- Move substitution logic from patterns to centralized template system
- Update patterns.go to use template package for variable processing
- Support special {{input}} handling for pattern content
- Update chatter.go and rest API to pass input parameter
- Enable multiple passes to handle nested variables
- Report errors for missing required variables
This change sets up a foundation for future templating features like front matter
and plugin support while keeping the substitution logic centralized.
- Stronger separation of concerns between chatter.go and patterns.go
- Consolidate pattern loading logic into GetPattern method
- Support both file and database patterns through single interface
- Maintain API compatibility with Storage interface
- Handle variable substitution in one place
- Keep backward compatibility for REST API through Get method
The changes enable cleaner pattern handling while maintaining
existing interfaces and adding file-based pattern support.
# What this Pull Request (PR) does
Add a new pattern to create a meeting summary from an audio transcript.
The pattern outputs the following sections (where relevant):
- Key Points
- Tasks
- Decisions
- Next Steps
Allow patterns to be loaded directly from files using explicit path prefixes
(~/, ./, /, or \). This enables easier testing and iteration of patterns
without requiring installation into the fabric config structure.
- Supports relative paths (./pattern.txt, ../pattern.txt)
- Supports home directory expansion (~/patterns/test.txt)
- Supports absolute paths
- Maintains backwards compatibility with named patterns
- Requires explicit path markers to distinguish from pattern names
Example usage:
fabric --pattern ./draft-pattern.txt
fabric --pattern ~/patterns/my-pattern.txt
fabric --pattern ../../shared-patterns/test.txt
