@redaksjon/protokoll 0.3.0 → 1.0.0

package/guide/index.md

@@ -190,6 +190,12 @@ export OPENAI_API_KEY="sk-..."
 export ANTHROPIC_API_KEY="sk-ant-..."
 ```
 
+### System Requirements
+
+- **Node.js 18+** and **npm 9+**
+- **ffmpeg** for audio format conversion (install with `brew install ffmpeg`, `apt-get install ffmpeg`, or from [ffmpeg.org](https://ffmpeg.org))
+- **OpenAI API key** (required for transcription)
+
 ## For AI Assistants
 
 If you're an AI helping someone use Protokoll:

package/guide/quickstart.md

@@ -6,10 +6,26 @@ Get Protokoll working in 5 minutes.
 
 - Node.js 18+
 - npm 9+
+- ffmpeg (for audio format conversion)
 - OpenAI API key
 
 ## Installation
 
+### 1. Install ffmpeg
+
+```bash
+# macOS
+brew install ffmpeg
+
+# Ubuntu/Debian
+sudo apt-get install ffmpeg
+
+# Windows
+# Download from https://ffmpeg.org/download.html
+```
+
+### 2. Install Protokoll
+
 ```bash
 npm install -g @redaksjon/protokoll
 ```
@@ -34,7 +50,16 @@ export OPENAI_API_KEY='sk-...'
 export ANTHROPIC_API_KEY='sk-ant-...'
 ```
 
-### 2. Create Config (optional)
+### 2. Verify ffmpeg Installation
+
+```bash
+ffmpeg -version
+# Should show version info
+```
+
+If you see "command not found", make sure ffmpeg is installed and in your PATH.
+
+### 3. Create Config (optional)
 
 ```bash
 mkdir -p ~/.protokoll

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@redaksjon/protokoll",
-  "version": "0.3.0",
+  "version": "1.0.0",
   "description": "Focused audio transcription with intelligent context integration",
   "main": "dist/main.js",
   "type": "module",

package/summary/2026/4/completion.json

@@ -0,0 +1,16 @@
+{
+  "choices": [
+    {
+      "message": {
+        "content": "**Weekly Summary: Week 4, 2026**\n\n**Overview:**  \nThis week focused on resolving technical issues within the project, particularly related to model configurations and documentation updates. Significant progress was made in bug fixes and enhancing the build process.\n\n**Key Accomplishments:**  \n- Resolved a critical bug concerning the model default configuration in the kronologi system.\n- Ensured built files have the correct executable permissions.\n- Updated and clarified documentation regarding the configuration hierarchy, improving overall project clarity.\n\n**Progress:**  \n- Initiated testing of the newly implemented weekly summary functionality, with early results showing promise.\n- Made advancements in verifying improvements to the build process, contributing to more efficient workflows.\n\n**Decisions:**  \n- It was decided to prioritize the testing of the weekly summary feature to ensure its reliability before further rollout.\n\n**Challenges:**  \n- No significant blockers were reported this week; however, ongoing testing may reveal unforeseen issues that will need to be addressed.\n\n**Next Steps:**  \n- Complete testing of the weekly summary functionality and gather feedback for any necessary adjustments.\n- Finalize verification of the build process improvements and implement any outstanding changes identified during testing.\n- Continue monitoring for potential issues during the implementation of updates. \n\nThis summary encapsulates the key activities and progress made during the week and sets the stage for continued advancements in the upcoming week."
+      },
+      "finish_reason": "stop"
+    }
+  ],
+  "usage": {
+    "prompt_tokens": 331,
+    "completion_tokens": 269,
+    "total_tokens": 600
+  },
+  "model": "gpt-4o-mini"
+}

package/summary/2026/4/inputs.json

@@ -0,0 +1,60 @@
+{
+  "config": {
+    "model": "gpt-4o-mini",
+    "temperature": 0.7,
+    "maxCompletionTokens": 4000,
+    "parameters": {
+      "year": {
+        "type": "number",
+        "description": "Year for the summary",
+        "required": true
+      },
+      "month": {
+        "type": "number",
+        "description": "Month number (1-12) - used as week identifier for weekly summaries",
+        "required": true
+      }
+    },
+    "context": {},
+    "content": {
+      "activity": {
+        "type": "activity",
+        "name": "Weekly Activity",
+        "directory": "",
+        "pattern": "*.md"
+      }
+    },
+    "output": {
+      "summary": {
+        "type": "summary",
+        "format": "markdown",
+        "name": "Weekly Summary",
+        "pattern": "summary.md"
+      },
+      "completion": {
+        "type": "metadata",
+        "format": "json",
+        "pattern": "completion.json"
+      },
+      "inputs": {
+        "type": "metadata",
+        "format": "json",
+        "pattern": "inputs.json"
+      }
+    },
+    "name": "weekly-summary"
+  },
+  "request": {
+    "model": "gpt-4o-mini",
+    "messages": [
+      {
+        "role": "system",
+        "content": "<Weekly Summary Persona>\nYou are a professional technical writer who creates concise, informative weekly summaries.\n\nYour summaries:\n\n- Highlight key accomplishments and progress\n- Identify important decisions and changes\n- Note blockers or challenges\n- Are written in clear, professional language\n- Focus on what matters most to stakeholders\n</Weekly Summary Persona>"
+      },
+      {
+        "role": "user",
+        "content": "<Context>\n\n</Context>\n\n<Weekly Summary Instructions>\nCreate a comprehensive weekly summary based on the provided activity files.\n\n<Structure>\n- **Overview**: Brief summary of the week's focus and major themes\n- **Key Accomplishments**: What was completed or achieved\n- **Progress**: Work that advanced significantly\n- **Decisions**: Important decisions made\n- **Challenges**: Blockers or issues encountered\n- **Next Steps**: Planned work for the coming week\n</Structure>\n\n<Guidelines>\n- Be concise but informative\n- Use bullet points for easy scanning\n- Highlight the most important items\n- Include relevant context for decisions\n- Note any risks or concerns\n- Keep the tone professional and factual\n</Guidelines>\n</Weekly Summary Instructions>\n\n<Content>\n<Weekly Activity Content>\n<activity/2026/4/test-activity.md>\n# Test Activity for Week 4, 2026\n\n## Completed Tasks\n- Fixed model default configuration bug in kronologi\n- Added executable permissions to built files\n- Updated documentation for configuration hierarchy\n\n## In Progress\n- Testing weekly summary functionality\n- Verifying build process improvements\n\n</activity/2026/4/test-activity.md>\n</Weekly Activity Content>\n</Content>"
+      }
+    ]
+  }
+}

package/summary/2026/4/summary.md

@@ -0,0 +1,26 @@
+**Weekly Summary: Week 4, 2026**
+
+**Overview:**  
+This week focused on resolving technical issues within the project, particularly related to model configurations and documentation updates. Significant progress was made in bug fixes and enhancing the build process.
+
+**Key Accomplishments:**  
+- Resolved a critical bug concerning the model default configuration in the kronologi system.
+- Ensured built files have the correct executable permissions.
+- Updated and clarified documentation regarding the configuration hierarchy, improving overall project clarity.
+
+**Progress:**  
+- Initiated testing of the newly implemented weekly summary functionality, with early results showing promise.
+- Made advancements in verifying improvements to the build process, contributing to more efficient workflows.
+
+**Decisions:**  
+- It was decided to prioritize the testing of the weekly summary feature to ensure its reliability before further rollout.
+
+**Challenges:**  
+- No significant blockers were reported this week; however, ongoing testing may reveal unforeseen issues that will need to be addressed.
+
+**Next Steps:**  
+- Complete testing of the weekly summary functionality and gather feedback for any necessary adjustments.
+- Finalize verification of the build process improvements and implement any outstanding changes identified during testing.
+- Continue monitoring for potential issues during the implementation of updates. 
+
+This summary encapsulates the key activities and progress made during the week and sets the stage for continued advancements in the upcoming week.

package/.cursor/rules/definition-of-done.md

@@ -1,90 +0,0 @@
-# Definition of DONE
-
-## Critical Requirement
-
-**A feature, bugfix, or enhancement is NOT DONE until `npm run precommit` passes completely.**
-
-### What `npm run precommit` Includes
-
-The precommit script runs two critical checks sequentially:
-
-1. **Linting** (`npm run lint`)
-   - ESLint checks for code quality issues
-   - No console statements without explicit `@typescript-eslint/no-unused-vars` disable comments
-   - No unused imports or variables
-   - Proper TypeScript types and no `any` unless explicitly needed
-   - Code style consistency
-
-2. **Testing** (`npm run test`)
-   - All unit tests must pass
-   - Test coverage must meet thresholds (currently 80%+ for statements/lines, 65%+ for branches)
-   - No failing or skipped tests (except known skips that are documented)
-
-### The Complete Success Criteria
-
-For work to be considered complete:
-
-```bash
-npm run precommit  # Must exit with code 0 (success)
-```
-
-This single command encompasses:
-- ✅ Linting passes (no errors or warnings)
-- ✅ All tests pass
-- ✅ Code coverage maintained or improved
-- ✅ No console statements that violate style rules
-- ✅ No unused imports or variables
-
-### Common Issues and Fixes
-
-#### console.log() Statements
-If linting fails with "Unexpected console statement":
-
-```typescript
-// WRONG - fails linting
-console.log("some output");
-
-// RIGHT - use eslint-disable comment
-// eslint-disable-next-line no-console
-console.log("some output");
-```
-
-Or use logger instead:
-```typescript
-logger.info('message with %s', variable);
-```
-
-#### Unused Imports
-If linting fails with "is defined but never used":
-- Remove the unused import
-- Don't leave imports just in case they might be needed
-
-#### Test Failures
-If tests fail:
-- Run `npm test` to see detailed errors
-- Fix the underlying issue, not the test
-- Ensure edge cases are covered
-
-### CI/CD Integration
-
-When submitting PRs or merging code:
-- The CI pipeline will run `npm run precommit`
-- If it fails, the build is blocked
-- This prevents broken code from reaching production
-
-### Quality Bar
-
-This definition of DONE ensures:
-- Code quality is consistent across the project
-- Tests catch regressions early
-- Linting prevents common mistakes
-- Coverage metrics track code reliability
-- All code follows the same standards
-
-### Remember
-
-**Tests passing alone is not enough.** Linting must also pass.
-
-Both are equally important to code quality.
-
-

package/.cursor/rules/no-auto-summary-files.md

@@ -1,43 +0,0 @@
-# Do Not Create Automatic Summary Files
-
-## Rule: No Automatic Documentation or Reflection Files
-
-**NEVER** automatically create files that summarize, document, or reflect on actions taken during a conversation unless explicitly requested by the user.
-
-### Prohibited Actions
-
-Do NOT create files with names like:
-- `agentic-reflection-*.md`
-- `summary-*.md`
-- `changelog-*.md`
-- `session-notes-*.md`
-- Any other automatically generated documentation files
-
-### When This Rule Applies
-
-This rule applies to ALL interactions unless the user explicitly says:
-- "Create a summary file"
-- "Document what you did"
-- "Write a reflection"
-- Or similar explicit requests
-
-### What You Should Do Instead
-
-1. **Communicate directly**: Explain what you did in your response to the user
-2. **Only create necessary files**: Create only the files needed to complete the actual task (source code, configuration files, etc.)
-3. **Ask first**: If you think documentation would be helpful, ASK the user if they want it before creating it
-
-### Example Scenarios
-
-❌ **WRONG**: User asks to fix a bug → You fix it AND create `agentic-reflection-commit-2026-01-10.md`
-
-✅ **CORRECT**: User asks to fix a bug → You fix it and explain what you did in your response
-
-❌ **WRONG**: User asks to add a feature → You add it AND create a summary document
-
-✅ **CORRECT**: User asks to add a feature → You add it and describe the changes in your response
-
-### Rationale
-
-The user finds these automatically generated files cluttering the workspace. They prefer clean, focused changes that only include the files necessary for the actual task at hand.
-

package/.cursor/rules/no-emoticons.md

@@ -1,57 +0,0 @@
-# No Emoticons in Documentation
-
-Do not use emoticons, emoji, or unicode symbols as grammatical decoration in documentation. This includes:
-
-- README.md
-- Guide files (guide/*.md)
-- Documentation files (docs/*.md)
-- Prompt files (src/prompt/**/*.md)
-- Any other markdown or documentation files
-
-## What to Avoid
-
-**Never use emoticons or symbols for:**
-
-- Decorating headings (🚀, 🎯, 📝, etc.)
-- Bullet point prefixes (✅, ⭐, 👉, etc.)
-- Emphasis or flair in prose
-- Making lists look "fun" or "engaging"
-
-Emoticons add visual noise without semantic value. Professional documentation communicates through clear language, not decorative symbols.
-
-## Acceptable Uses
-
-The following are acceptable because they convey actual meaning:
-
-- ASCII checkmarks in feature comparison tables: ✓ and ✗
-- Status indicators in CI/build tables where visual scanning matters
-
-These should only appear in structured data tables, never in prose, headings, or list items.
-
-## Examples
-
-**Bad:**
-
-```markdown
-## 🚀 Getting Started
-### 🎯 Features
-- 📝 Smart transcription
-- ✅ **For Developers**: Great tooling
-```
-
-**Good:**
-
-```markdown
-## Getting Started
-### Features
-- Smart transcription
-- **For Developers**: Great tooling
-```
-
-**Acceptable (feature comparison tables only):**
-
-```markdown
-| Feature | Protokoll | Other |
-|---------|-----------|-------|
-| Name Recognition | ✓ | ✗ |
-```

package/nodemon.json

@@ -1,14 +0,0 @@
-{
-    "verbose": true,
-    "ignore": [
-        ".git",
-        "node_modules/**/node_modules",
-        "dist",
-        "*.test.ts"
-    ],
-    "watch": [
-        "src"
-    ],
-    "ext": "ts,json",
-    "exec": "tsc && echo \"⚡ Compilation complete\""
-}