feat: Add --oneline argument to allow post-processing output

implements #171

Author: timabell

.claude/agents/code-reviewer.md

@@ -0,0 +1,60 @@
+---
+name: code-reviewer
+description: Use this agent when you have written or modified code and need a thorough review before committing. This agent should be called after completing a logical chunk of work but before running git commit. Examples: <example>Context: User has just implemented a new feature for markdown parsing. user: 'I've added support for parsing metadata properties in markdown files. Here's the diff...' assistant: 'Let me use the code-reviewer agent to review this implementation before you commit.' <commentary>Since the user has completed a code change, use the code-reviewer agent to analyze the diff for quality, design, and architectural alignment.</commentary></example> <example>Context: User has refactored a component in the Dioxus UI. user: 'I refactored the file browser component to use better state management' assistant: 'I'll review this refactoring with the code-reviewer agent to ensure it follows best practices.' <commentary>The user has made changes that need review before committing, so use the code-reviewer agent.</commentary></example>
+tools: Task, Bash, Glob, Grep, LS, Read, Edit, MultiEdit, Write, NotebookEdit, WebFetch, TodoWrite, WebSearch, BashOutput, KillBash
+model: inherit
+color: orange
+---
+
+You are a Senior Software Architect and Code Quality Expert specializing in Rust development, with deep expertise in the markdown-neuraxis project architecture. Your role is to conduct thorough code reviews focusing on quality, design decisions, and architectural alignment.
+
+YOU ARE FORBIDDEN TO MAKE ANY FILESYSTEM CHANGES
+
+When reviewing code diffs, you will systematically evaluate:
+
+**Code Quality & Craftsmanship:**
+- Identify shortcuts, hacks, or technical debt that compromise maintainability
+- Flag poor error handling, unsafe code patterns, or resource leaks
+- Check for proper use of Rust idioms, ownership patterns, and type safety
+- Verify adherence to the project's coding standards (cargo fmt, cargo clippy compliance)
+- Assess code readability, documentation, and self-explanatory naming
+- Parsing code must NEVER be in the UI code files
+
+**Design & Architecture:**
+- Ensure changes align with the project's local-first, markdown-centric philosophy
+- Verify compatibility with the Dioxus desktop framework and plugin architecture
+- Check that new code follows established patterns for file system access and markdown parsing
+- Assess impact on the PARA methodology implementation and fractal outline structure
+- Validate that UI changes maintain keyboard-first, split-view design principles
+
+**Test Coverage & Quality:**
+- Identify missing test coverage for new functionality
+- Suggest integration tests following the outside-in testing strategy
+- Flag changes that break existing test contracts
+- Recommend test scenarios for edge cases and error conditions
+- as a reviewer, if you can't tell from the tests if it works, then the feedback should include that the test coverage is not clear or sufficient
+
+**Project-Specific Concerns:**
+- Ensure markdown parsing changes maintain compatibility with pulldown-cmark
+- Verify file organization works with flexible folder structures (journal/, assets/ are optional)
+- Check that cross-linking and UUID systems remain intact
+- Validate performance implications for large markdown file collections
+
+**Review Process:**
+1. Analyze the diff context and identify the change's purpose
+2. Systematically evaluate each modified file against the criteria above
+3. Prioritize findings by severity: Critical (blocks commit), Major (should fix), Minor (consider fixing)
+4. Provide specific, actionable feedback with code examples when helpful
+5. Suggest concrete improvements or alternative approaches
+6. Highlight positive aspects and good practices observed
+
+**Output Format:**
+Structure your review as:
+- **Summary**: Brief assessment of overall change quality
+- **Critical Issues**: Must-fix problems that should block the commit
+- **Major Concerns**: Important issues that should be addressed soon
+- **Minor Suggestions**: Improvements for consideration
+- **Positive Notes**: Well-implemented aspects worth highlighting
+- **Recommendation**: APPROVE, APPROVE WITH CHANGES, or NEEDS WORK
+
+Be thorough but constructive. Focus on teaching and improving rather than just finding faults. Consider the change's context within the broader project goals.

.claude/agents/feature-implementor.md

@@ -0,0 +1,43 @@
+---
+name: feature-implementer
+description: Use this agent when you need to implement a specific bug fix or feature request. This agent should be called when you have a clear requirement or issue that needs to be coded and tested. Examples: <example>Context: User wants to add a new markdown parsing feature to handle custom metadata blocks. user: 'I need to add support for parsing custom metadata blocks in markdown files like `property:: value` format' assistant: 'I'll use the feature-implementer agent to implement this markdown metadata parsing feature with proper tests.' <commentary>Since the user has a specific feature request that needs implementation, use the feature-implementer agent to write the code and tests.</commentary></example> <example>Context: User reports a bug where the file browser crashes on empty directories. user: 'The file browser is crashing when I open an empty directory - can you fix this?' assistant: 'I'll use the feature-implementer agent to investigate and fix this file browser crash bug.' <commentary>Since there's a specific bug that needs fixing, use the feature-implementer agent to diagnose and implement the fix.</commentary></example>
+tools: Task, Bash, Glob, Grep, LS, ExitPlanMode, Read, Edit, MultiEdit, Write, NotebookEdit, WebFetch, TodoWrite, WebSearch, BashOutput, KillBash
+model: opus
+color: blue
+---
+
+You are a senior software engineer with deep expertise in Rust, Dioxus, and markdown processing systems. You specialize in implementing features and fixing bugs with a focus on clean, maintainable code that follows KISS and YAGNI principles.
+
+Your core responsibilities:
+- Implement requested features or bug fixes completely and correctly
+- Write comprehensive outside-in tests that verify behavior from the user's perspective
+- Ensure all code follows project conventions and architecture patterns
+- Address code review feedback thoroughly and make necessary changes
+- Always deliver working code with passing tests before considering the task complete
+
+Your approach to implementation:
+1. **Understand the requirement**: Analyze the feature/bug request in context of the project's architecture and goals
+2. **Design the solution**: Plan the implementation considering existing patterns, KISS principles, and avoiding over-engineering
+3. **Implement incrementally**: Write code in small, testable chunks that build toward the complete solution
+4. **Test outside-in**: Create integration tests that verify the feature works from the user's perspective, then add unit tests as needed
+5. **Verify quality**: Ensure code follows Rust best practices, project conventions, and passes all linting
+6. **Handle feedback**: When receiving code review feedback, address all points thoroughly and make necessary improvements
+
+Key technical guidelines:
+- Follow the project's file structure and architectural patterns established in CLAUDE.md
+- Use Dioxus patterns consistently with existing codebase
+- Prefer composition over inheritance and simple solutions over complex ones
+- Write tests that focus on behavior rather than implementation details
+- Avoid mocking in favor of testing real integrations where practical
+- Ensure all code is formatted with `cargo fmt` and passes `cargo clippy`
+- Make atomic commits with clear conventional commit messages
+- When you are ready to commit, exit and tell the calling agent that the code is ready, do not make any git commits.
+
+Quality standards:
+- All tests must pass before considering implementation complete
+- Code must be self-documenting with clear variable and function names
+- Handle error cases gracefully with appropriate error types
+- Consider edge cases and boundary conditions in both code and tests
+- Ensure thread safety and performance considerations for file system operations
+
+When you encounter ambiguity or need clarification, ask specific questions rather than making assumptions. Take pride in delivering robust, well-tested code that enhances the project's goals of being a reliable, local-first markdown knowledge management system.

.claude/settings.local.json

@@ -0,0 +1,24 @@
+{
+  "$schema": "https://json.schemastore.org/claude-code-settings.json",
+  "permissions": {
+    "allow": [
+      "Bash(find:*)",
+      "Bash(cat:*)",
+      "Bash(mkdir:*)",
+      "Bash(grep:*)",
+      "Bash(./lint.sh)",
+      "Bash(cargo build)",
+      "Bash(cargo test)",
+      "Bash(cargo fmt:*)",
+      "Bash(cargo test:*)",
+      "Bash(cargo clippy:*)",
+      "Bash(cargo check:*)",
+      "Bash(cargo insta:*)",
+      "Bash(cargo doc:*)",
+      "WebFetch(domain:crates.io)",
+      "WebFetch(domain:docs.rs)",
+      "WebFetch(domain:github.com)"
+    ],
+    "deny": []
+  }
+}

CLAUDE.md

@@ -0,0 +1,56 @@
+# CLAUDE.md
+
+This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
+
+## Commands
+
+### Building and Testing
+- **Build**: `cargo build`
+- **Run tests**: `cargo test`
+- **Run a specific test**: `cargo test test_name`
+- **Run end-to-end tests**: `cargo test --test end_to_end_tests`
+- **Run gitopolis tests**: `cargo test --test gitopolis_tests`
+
+### Linting and Formatting
+- **Run all lints**: `./lint.sh` (runs cargo fmt, clippy with harsh settings, cargo deny license check, and yamllint for GitHub workflows)
+- **Format code**: `cargo fmt`
+- **Run clippy**: `./clippy-harsh.sh` or `cargo clippy --all-targets --all-features -- -D warnings`
+- **Check licenses**: `cargo deny check licenses`
+- **Check unused dependencies**: `cargo machete`
+
+### Development
+- **Install CI tools locally**: `./ci-tool-setup.sh` (installs cargo-deny and yamllint)
+- **Upgrade dependencies**: `./upgrades.sh` (upgrades both Rust version and crate dependencies)
+
+## Architecture
+
+Gitopolis is a CLI tool for managing multiple git repositories, built in Rust with a clean separation of concerns:
+
+### Core Components
+
+- **main.rs**: CLI interface using clap, bridges between console and logic, injects dependencies
+- **lib.rs**: Module aggregation point for the library
+- **gitopolis.rs**: Core business logic with injected dependencies (storage, git operations, stdout)
+- **repos.rs**: Domain models for repository state management
+- **exec.rs**: Command execution across multiple repositories
+- **storage.rs**: Trait for state persistence (currently using TOML file `.gitopolis.toml`)
+- **git.rs**: Trait for git operations (using git2 crate)
+
+### Testing Strategy
+
+- **End-to-end tests** (`tests/end_to_end_tests.rs`): Test complete workflows with real file system and git repos
+- **Unit tests** (`tests/gitopolis_tests.rs`): Test core logic with mocked dependencies (storage, git)
+
+### Key Design Patterns
+
+- Dependency injection through traits for testability (Storage, Git traits)
+- Clean separation between CLI parsing and business logic
+- State management through `.gitopolis.toml` file with TOML serialization
+- Command pattern for different operations (add, remove, exec, tag, clone, list)
+
+### Important Notes
+
+- The tool uses `git2` crate for git operations with vendored OpenSSL
+- Windows has special handling for glob expansion (not done by shell)
+- Currently only supports "origin" remote (see issue #7 for multiple remote support)
+- Rust version is pinned in `.tool-versions` and used by CI workflows

README.md

@@ -29,6 +29,16 @@ gitopolis add *
 gitopolis exec -- git pull
 ```
 
+### Getting output as single lines
+
+For compact, parsable output that's easy to sort and analyze use `--oneline`, this will put all the output on a single line for each repo (removing newlines).
+
+e.g. to see the latest commit for all the repos, with the most recently touched repo first:
+
+```sh
+gitopolis exec --oneline -- git log --format=format:'%cd "%s" 📝 %an' --date='format:%Y-%m-%d' -n 1 | awk '{print $3 " " $0}' | sort -r
+```
+
 ### Tagging
 
 ```sh

src/exec.rs

@@ -1,9 +1,9 @@
 use crate::repos::Repo;
 use std::env;
-use std::io::Error;
-use std::process::{Child, Command, ExitStatus};
+use std::io::{Error, Read};
+use std::process::{Child, Command, ExitStatus, Stdio};
 
-pub fn exec(mut exec_args: Vec<String>, repos: Vec<Repo>) {
+pub fn exec(mut exec_args: Vec<String>, repos: Vec<Repo>, oneline: bool) {
 	let args = exec_args.split_off(1);
 	let cmd = &exec_args[0]; // only cmd remaining after split_off above
 	let mut error_count = 0;
@@ -12,11 +12,24 @@ pub fn exec(mut exec_args: Vec<String>, repos: Vec<Repo>) {
 			println!("🏢 {}> Repo folder missing, skipped.", &repo.path);
 			return;
 		}
-		let exit_status = repo_exec(&repo.path, cmd, &args).expect("Failed to execute command.");
-		if !exit_status.success() {
-			error_count += 1
+		if oneline {
+			let (output, success) =
+				repo_exec_oneline(&repo.path, cmd, &args).expect("Failed to execute command.");
+			match output {
+				Some(output_text) => println!("🏢 {}> {}", &repo.path, output_text),
+				None => println!("🏢 {}> ", &repo.path),
+			}
+			if !success {
+				error_count += 1;
+			}
+		} else {
+			let exit_status =
+				repo_exec(&repo.path, cmd, &args).expect("Failed to execute command.");
+			if !exit_status.success() {
+				error_count += 1
+			}
+			println!();
 		}
-		println!();
 	}
 	if error_count > 0 {
 		eprintln!("{error_count} commands exited with non-zero status code");
@@ -45,3 +58,52 @@ fn repo_exec(path: &str, cmd: &str, args: &Vec<String>) -> Result<ExitStatus, Er
 	}
 	Ok(*exit_code)
 }
+
+fn repo_exec_oneline(
+	path: &str,
+	cmd: &str,
+	args: &Vec<String>,
+) -> Result<(Option<String>, bool), Error> {
+	let mut child_process: Child = Command::new(cmd)
+		.args(args)
+		.current_dir(path)
+		.stdout(Stdio::piped())
+		.stderr(Stdio::piped())
+		.spawn()?;
+
+	let mut stdout = String::new();
+	if let Some(mut stdout_pipe) = child_process.stdout.take() {
+		stdout_pipe.read_to_string(&mut stdout)?;
+	}
+
+	let mut stderr = String::new();
+	if let Some(mut stderr_pipe) = child_process.stderr.take() {
+		stderr_pipe.read_to_string(&mut stderr)?;
+	}
+
+	let exit_code = child_process.wait()?;
+	let success = exit_code.success();
+
+	// Flatten multi-line output to single line by replacing newlines with spaces
+	let stdout_clean = stdout.trim().replace('\n', " ");
+	let stderr_clean = stderr.trim().replace('\n', " ");
+
+	// Combine stdout and stderr, with stderr included when command fails
+	let output = if !success && !stderr_clean.is_empty() {
+		if stdout_clean.is_empty() {
+			stderr_clean
+		} else {
+			format!("{} {}", stdout_clean, stderr_clean)
+		}
+	} else if !stdout_clean.is_empty() {
+		stdout_clean
+	} else {
+		String::new()
+	};
+
+	if output.is_empty() {
+		Ok((None, success))
+	} else {
+		Ok((Some(output), success))
+	}
+}

src/main.rs

@@ -40,6 +40,8 @@ enum Commands {
 	Exec {
 		#[arg(short, long)]
 		tag: Option<String>,
+		#[arg(long)]
+		oneline: bool,
 		exec_args: Vec<String>,
 	},
 	/// Add/remove repo tags. Use tags to organise repos and allow running commands against subsets of the repo list.
@@ -89,13 +91,15 @@ fn main() {
 		Some(Commands::Clone { tag: tag_name }) => clone(tag_name),
 		Some(Commands::Exec {
 			tag: tag_name,
+			oneline,
 			exec_args,
 		}) => {
 			exec(
 				exec_args.to_owned(),
 				init_gitopolis()
 					.list(tag_name)
 					.expect("TODO: panic message"),
+				*oneline,
 			);
 		}
 		Some(Commands::Tag {

tests/end_to_end_tests.rs

@@ -411,6 +411,61 @@ fn exec_invalid_command() {
 		.failure();
 }
 
+#[test]
+fn exec_oneline() {
+	let temp = temp_folder();
+	add_a_repo(&temp, "repo_a", "git://example.org/test_url");
+	add_a_repo(&temp, "repo_b", "git://example.org/test_url2");
+
+	gitopolis_executable()
+		.current_dir(&temp)
+		.args(vec!["exec", "--oneline", "--", "echo", "hello"])
+		.assert()
+		.success()
+		.stdout("🏢 repo_a> hello\n🏢 repo_b> hello\n");
+}
+
+#[test]
+fn exec_oneline_multiline_output() {
+	let temp = temp_folder();
+	add_a_repo(&temp, "repo_a", "git://example.org/test_url");
+
+	// Create a test file with multiple lines in the repo
+	let repo_path = temp.path().join("repo_a");
+	fs::write(repo_path.join("test.txt"), "line1\nline2\nline3").unwrap();
+
+	gitopolis_executable()
+		.current_dir(&temp)
+		.args(vec!["exec", "--oneline", "--", "cat", "test.txt"])
+		.assert()
+		.success()
+		.stdout("🏢 repo_a> line1 line2 line3\n");
+}
+
+#[test]
+fn exec_oneline_non_zero() {
+	let temp = temp_folder();
+	add_a_repo(&temp, "repo_a", "git://example.org/test_url");
+	add_a_repo(&temp, "repo_b", "git://example.org/test_url2");
+
+	let expected_stdout = match get_operating_system() {
+		OperatingSystem::MacOSX => {
+			"🏢 repo_a> ls: non-existent: No such file or directory\n🏢 repo_b> ls: non-existent: No such file or directory\n"
+		}
+		OperatingSystem::Other => {
+			"🏢 repo_a> ls: cannot access 'non-existent': No such file or directory\n🏢 repo_b> ls: cannot access 'non-existent': No such file or directory\n"
+		}
+	};
+
+	gitopolis_executable()
+		.current_dir(&temp)
+		.args(vec!["exec", "--oneline", "--", "ls", "non-existent"])
+		.assert()
+		.success()
+		.stdout(expected_stdout)
+		.stderr("2 commands exited with non-zero status code\n");
+}
+
 #[test]
 fn tag() {
 	let temp = temp_folder();