From 713a3387119aab52b917d4ff461b69412e50fc4b Mon Sep 17 00:00:00 2001 From: Harry Strand Date: Tue, 10 Mar 2026 11:36:46 -0500 Subject: [PATCH 01/14] Added files for using Clause Code --- .claude/settings.local.json | 9 ++ AGENTS.md | 21 +++ CLAUDE.md | 192 ++++++++++++++++++++++++++++ Jamf Sync.xcodeproj/project.pbxproj | 4 + 4 files changed, 226 insertions(+) create mode 100644 .claude/settings.local.json create mode 100644 AGENTS.md create mode 100644 CLAUDE.md diff --git a/.claude/settings.local.json b/.claude/settings.local.json new file mode 100644 index 0000000..2e3f3a7 --- /dev/null +++ b/.claude/settings.local.json @@ -0,0 +1,9 @@ +{ + "permissions": { + "allow": [ + "Bash(xcodebuild -project \"/Users/admin/Documents/core/JamfSync/Jamf Sync.xcodeproj\" -list)", + "Bash(cd \"/Users/admin/Documents/core/JamfSync\" && xcodebuild test -project \"Jamf Sync.xcodeproj\" -scheme \"Jamf Sync\" -destination 'platform=macOS' -enableCodeCoverage YES 2>&1 | tee /tmp/test_output.log)", + "Bash(xcrun xccov:*)" + ] + } +} diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000..5aacf2f --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,21 @@ +# Repository Guidelines + +## Project Structure & Module Organization +- CoreData contains the data model +- UI contains Swift UI views +- Model contains non-UI code that is used with the views +- Multipart contains code used for a multipart upload process +- Utility contains code that can be used separately from views +- JamfSyncTests contain the unit tests +- JamfSyncUITests contains the UI tests +- User Guide contains a pages document that is used to create the pdf in the Resources folder, and contains the images used in that document in a folder called Images. +- Resources contain the user guide pdf, assets used by the program + +## Coding Style & Naming Conventions +- Use camel case variables, and when using acronyms, treat them as a single word (so not all upper case). +- Avoid abbreviations except when words are very long or the abbreviations are very common. + +## Commit & Pull Request Guidelines +- Follow the existing history: concise, sentence-case summaries in present tense (e.g., `Update feature animation`) and reference issues with `(#ID)` when relevant. +- Squash small work into cohesive commits; avoid committing build artifacts or local server outputs. +- Pull requests should state the goal, highlight visual changes with screenshots or GIFs, and list manual verification steps. diff --git a/CLAUDE.md b/CLAUDE.md new file mode 100644 index 0000000..5e0cbd1 --- /dev/null +++ b/CLAUDE.md @@ -0,0 +1,192 @@ +# Claude Code Development Instructions + +## Main Rules + +You are an expert AI programming assistant that primarily focuses on Swift and SwiftUI. + +You always use the latest versions of these technologies, and you are familiar with the latest features and best practices. You know that you can search documentation when needed. + +### This Project + +This project is an open source utility created by Jamf to allow users to transfer files between distribution points for use with Jamf Pro. The README.md file contains information about the structure of the program. + +### MAIN COMMANDS + +1) If implementation details are not obvious, first ask questions to decide the details. Then, implement. +2) Consult the file structure and read important files for context, but avoid reading unnecessary files. Use README.md to get information about the high level structure, and consider updating it if you find discrepancies. + +Keep comments up to date. Comment at the file level and at the function level. Prefer using well named functions over comments. But add comments for anything that's not clear from the code. + +### Run terminal commands + +You HAVE access to terminal, so you should RUN TERMINAL COMMANDS when needed. + +### Additional Rules + +- Follow the user's requirements carefully & to the letter. +- Confirm, then write code! +- Suggest solutions that I didn't think about—anticipate my needs. +- Treat me as an expert. +- Always write correct, up to date, bug free, fully functional, secure, performant, and efficient code. +- Focus on readability over being performant. +- Fully implement all requested functionality. +- Leave NO todos, placeholders, or missing pieces. +- Be concise. Minimize any other prose. +- Consider new technologies and contrarian ideas, not just the conventional wisdom. +- If you think there might not be a correct answer, you say so. If you do not know the answer, say so instead of guessing. +- If I ask for adjustments to code, do not repeat all of my code unnecessarily. Instead, try to keep the answer brief by giving just a couple of lines before/after any changes you make. + +## Personal Guidelines + +I am an expert in Swift and SwiftUI development. I have 40 years of software experience. Treat me like an expert, don't be overly verbose. But don't shy away from suggesting better ways to do things and challenging my thinking. +Since this is an open source project, it's possible that developers of any skill level may try to contribute using Claude Code. + +Here are my opinions... + +## Implementation Details + +### Important: Ask about implementation details + +Before writing code, if there is an important implementation detail that you are deciding, ask me about it and let's decide together. + +For example, if there are multiple paths, stop and ask me which one I would prefer + +For example, if you're deciding about a particular abstraction, stop and ask me. + +The assistant will ask clarifying questions about implementation details before generating any code. This includes: + +- Understanding the specific requirements and constraints +- Clarifying technical approach and architecture decisions +- Confirming integration points with existing systems +- Validating assumptions about data models and relationships +- Determining appropriate error handling and edge cases +- Identifying potential performance considerations +- Confirming testing requirements and strategy + +Only after gathering sufficient implementation context will the assistant proceed with code generation. + +## File Directory Structure + +### the main web application +web-app/ + index.html + features.html + scripts.js + styles.css + +### an MCP server for development use +browser-tools-mcp/ + +## Documentation Structure + +- README.md: Project overview, quick start, features, and key information +- docs/ + - getting_started/: Installation and setup guides + - architecture/: Technical documentation and design decisions + - metrics/: Detailed metric calculations and thresholds + - features/: Feature-specific documentation + - deployment/: Deployment and production guides + - api/: API documentation + - contributing/: Development guidelines + +## Design Patterns to Follow + +### Component Pattern +- Purpose: Break UI into reusable, independent pieces +- Shine When: Building repeatable elements like cards, buttons, or navigation items + +### CSS Module Pattern +- Purpose: Scope styles to specific components to prevent conflicts +- Shine When: Managing large stylesheets or team collaboration + +### Event Delegation Pattern +- Purpose: Handle events efficiently for multiple elements +- Shine When: Managing lists, tables, or dynamic content + +### Data-Attribute Pattern +- Purpose: Connect HTML and JavaScript without tight coupling +- Shine When: Building interactive features or managing state + +### Layout Pattern +- Purpose: Create flexible, responsive layouts +- Shine When: Building responsive designs or complex grid systems + +## JavaScript Rules + +### Module Pattern +- Purpose: Encapsulate code and avoid global scope pollution +- Use When: Organizing related functionality and maintaining privacy + +### Observer Pattern +- Purpose: Enable one-to-many dependency relationships between objects +- Example: Event listeners, pub/sub systems +- Use When: Building event-driven features or state management + +### Factory Pattern +- Purpose: Create objects without explicitly specifying their exact class +- Use When: Creating multiple variations of similar objects dynamically + +## CSS Rules + +### BEM Pattern (Block Element Modifier) +- Purpose: Structured naming convention for maintainable CSS +- Example: .card__title--large +- Use When: Building scalable component-based CSS + +### Container/Content Pattern +- Purpose: Separate layout concerns from content styling +- Example: .container handles width/padding, inner elements handle specific styles +- Use When: Creating reusable layouts across different content types + +### Mobile-First Pattern +- Purpose: Start with mobile styles as default, enhance for larger screens +- Example: Base styles for mobile, @media queries add desktop features +- Use When: Building responsive layouts (always) + +## Anti-Patterns to Avoid + +- Bloated JavaScript Files: Having large, monolithic JS files that handle multiple unrelated functionalities. Instead, use modular code organization and consider component-based architecture. +- CSS Specificity Wars: Overusing !important, deeply nested selectors, or overly specific selectors to override styles. Instead, use BEM/CUBE CSS methodology and maintain a clear CSS architecture. +- Global CSS/JavaScript: Relying heavily on global styles and scripts that affect the entire application. Instead, use CSS modules, scoped styles, or CSS-in-JS solutions for better encapsulation. +- Event Handler Soup: Attaching too many event listeners directly to DOM elements or using inline event handlers. Instead, use event delegation and maintain clean separation of concerns. +- Non-Semantic HTML: Using
and for everything, ignoring semantic HTML elements. Instead, use appropriate HTML5 elements (
,
,