initial commit - work in progress

.cursorrules

@@ -0,0 +1,99 @@
+# Instructions
+
+When helping the user with code, write like you're having a chat. If the user chooses to get you to read this document, it means they would like you to use a more informal, conversational style, like a couple of relaxed senior developers that have a great work/life balance.
+
+Don't get too formal or structured with the docs - just write like you're explaining what you're doing to a colleague. Think of it as pair programming, but you're documenting your thought process as we go.
+
+For example, instead of:
+"Migration script executed successfully. File verification completed."
+
+Write more like:
+"Cool, the script ran and moved everything where it needed to go. Double-checked all the files are there too."
+
+A few things that help keep it natural:
+
+- Tell me what you're thinking about trying next
+- If something seems off, just say so - like "hey, that import looks weird"
+- Use emojis if they help explain the mood or what's happening 🤔
+- Keep it flowing like a real conversation
+- If you're not sure about something, just ask
+
+The goal is to make it feel like we're sitting next to each other working through this stuff together. No need to get fancy with the documentation - just keep it clear and conversational.
+
+Remember: We're not writing a formal spec here, we're just two devs figuring stuff out and keeping notes so we remember what we did later.
+
+# Memory Management
+
+Hey future me! When working with users on large codebases, keep these tips in mind to stay performant:
+
+1. File Tracking:
+   - Only track files we're actively working on
+   - Drop tracking of files we've finished with
+   - Let the user know when you're dropping files, like:
+     "I'll stop tracking those other files for now to keep things snappy!"
+
+2. Conversation History:
+   - Regularly prune old parts of the conversation that aren't relevant
+   - Keep the current task's context and drop the rest
+   - Tell the user when you're doing this:
+     "Mind if I clear some of our older chat history? We've moved past that part!"
+
+3. Context Management:
+   - Focus on one feature/component at a time
+   - Ask the user if you can drop context of completed tasks
+   - Keep error messages and build outputs only while relevant
+
+Example conversation:
+User: "Here are 50 files to look at..."
+You: "Hey, that's a lot to keep in memory! Mind if I focus on just the files we're working on right now? I can drop the others and pick them up again when we need them."
+
+Remember: Being transparent about memory management helps the user understand why you might need to reload files or ask for context again.
+
+# Writing Style Examples
+
+Hey! When we're chatting about code and planning changes, let's keep things pretty casual and collaborative. But when documenting what we did, we should keep that clear and professional.
+
+Here's what I mean:
+
+When we're discussing changes, it's totally fine to say:
+"I'm thinking we could use a script to handle all these file moves - what do you reckon?"
+
+But when documenting the actual changes, we want something more like:
+"Migration script implemented to relocate files according to the new directory structure. Verification steps added to ensure file integrity post-migration."
+
+Some guidelines:
+
+- Keep our discussions natural and collaborative
+- Document decisions and changes formally
+- Include clear rationale for technical choices
+- Maintain professional tone in documentation
+
+Python scripts are really handy for automating file operations and text processing. Discuss the approach that would work best for the user's specific needs.
+
+Remember: While we can be casual in our planning discussions, the documentation needs to be clear and professional for future maintainers.
+
+# Folder Structure Philosophy
+
+Hey! When it comes to organizing code, let's keep it simple and lean:
+
+1. Start Flat 🥞
+   - Keep everything in their root-most folder initially
+   - Don't create subfolders until they're actually needed
+   - Let the complexity emerge naturally
+
+2. When to Add Subfolders 📁
+   - Wait until you have a clear pattern of related files
+   - Only add the subfolder that makes sense right now
+   - Don't create deep structures preemptively
+
+Example conversation:
+You: "Should we create components/nodes/utils/helpers now?"
+Me: "Nah, let's just keep it in components/ for now. We can move stuff when it gets crowded!"
+
+Remember: YAGNI (You Ain't Gonna Need It) applies to folder structure too. It's easier to:
+- Start flat and organize later
+- Add structure when it's obviously needed
+- Keep things visible at the root level
+- Avoid premature categorization
+
+Think of it like organizing your desk - you don't create a complex filing system for three pieces of paper! 📝

.github/config.yml

@@ -0,0 +1,11 @@
+blank_issues_enabled: false
+contact_links:
+  - name: "📚 Documentation"
+    url: "https://github.com/jameswilliamknight/was-doing/wiki"
+    about: "Check out our documentation before creating an issue"
+  - name: "💬 Discussions"
+    url: "https://github.com/jameswilliamknight/was-doing/discussions"
+    about: "Please ask and answer questions here"
+  - name: "🤝 Commercial Use"
+    url: "https://github.com/jameswilliamknight/was-doing#license-"
+    about: "Contact us about commercial licensing"

.github/dependabot.yml

@@ -0,0 +1,34 @@
+version: 2
+updates:
+  # Python dependencies
+  - package-ecosystem: "pip"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+      day: "monday"
+    open-pull-requests-limit: 10
+    labels:
+      - "dependencies"
+      - "python"
+    reviewers:
+      - "jknightdev"
+    assignees:
+      - "jknightdev"
+
+  # GitHub Actions
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+      day: "monday"
+    open-pull-requests-limit: 10
+    labels:
+      - "dependencies"
+      - "github-actions"
+    commit-message:
+      prefix: "⬆️ "
+      include: "scope"
+    reviewers:
+      - "jknightdev"
+    assignees:
+      - "jknightdev"

.gitignore

@@ -1,162 +1,33 @@
-# Byte-compiled / optimized / DLL files
+# Python virtual environment
+.venv/
+venv/
+ENV/
+
+# Python cache files
 __pycache__/
 *.py[cod]
 *$py.class
 
-# C extensions
-*.so
-
 # Distribution / packaging
-.Python
-build/
-develop-eggs/
 dist/
-downloads/
-eggs/
-.eggs/
-lib/
-lib64/
-parts/
-sdist/
-var/
-wheels/
-share/python-wheels/
+build/
 *.egg-info/
-.installed.cfg
-*.egg
-MANIFEST
-
-# PyInstaller
-#  Usually these files are written by a python script from a template
-#  before PyInstaller builds the exe, so as to inject date/other infos into it.
-*.manifest
-*.spec
-
-# Installer logs
-pip-log.txt
-pip-delete-this-directory.txt
-
-# Unit test / coverage reports
-htmlcov/
-.tox/
-.nox/
-.coverage
-.coverage.*
-.cache
-nosetests.xml
-coverage.xml
-*.cover
-*.py,cover
-.hypothesis/
-.pytest_cache/
-cover/
-
-# Translations
-*.mo
-*.pot
-
-# Django stuff:
-*.log
-local_settings.py
-db.sqlite3
-db.sqlite3-journal
-
-# Flask stuff:
-instance/
-.webassets-cache
-
-# Scrapy stuff:
-.scrapy
-
-# Sphinx documentation
-docs/_build/
-
-# PyBuilder
-.pybuilder/
-target/
-
-# Jupyter Notebook
-.ipynb_checkpoints
-
-# IPython
-profile_default/
-ipython_config.py
-
-# pyenv
-#   For a library or package, you might want to ignore these files since the code is
-#   intended to run in multiple environments; otherwise, check them in:
-# .python-version
-
-# pipenv
-#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
-#   However, in case of collaboration, if having platform-specific dependencies or dependencies
-#   having no cross-platform support, pipenv may install dependencies that don't work, or not
-#   install all needed dependencies.
-#Pipfile.lock
-
-# poetry
-#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
-#   This is especially recommended for binary packages to ensure reproducibility, and is more
-#   commonly ignored for libraries.
-#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
-#poetry.lock
-
-# pdm
-#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
-#pdm.lock
-#   pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
-#   in version control.
-#   https://pdm.fming.dev/latest/usage/project/#working-with-version-control
-.pdm.toml
-.pdm-python
-.pdm-build/
-
-# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
-__pypackages__/
-
-# Celery stuff
-celerybeat-schedule
-celerybeat.pid
-
-# SageMath parsed files
-*.sage.py
-
-# Environments
-.env
-.venv
-env/
-venv/
-ENV/
-env.bak/
-venv.bak/
-
-# Spyder project settings
-.spyderproject
-.spyproject
-
-# Rope project settings
-.ropeproject
-
-# mkdocs documentation
-/site
-
-# mypy
-.mypy_cache/
-.dmypy.json
-dmypy.json
 
-# Pyre type checker
-.pyre/
+# Database files
+*.db
+*.sqlite
+*.sqlite3
 
-# pytype static type analyzer
-.pytype/
+# Generated markdown files
+*.md
+!README.md
 
-# Cython debug symbols
-cython_debug/
+# IDE specific files
+.idea/
+.vscode/
+*.swp
+*.swo
 
-# PyCharm
-#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
-#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
-#  and can be added to the global gitignore or merged into this file.  For a more nuclear
-#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
-#.idea/
+# Operating System
+.DS_Store
+Thumbs.db

LICENSE

@@ -0,0 +1,42 @@
+"Commons Clause" License Condition v1.0
+
+The Software is provided to you by the Licensor under the License, as defined below, subject to the following condition.
+
+Without limiting other conditions in the License, the grant of rights under the License will not include, and the License does not grant to you, the right to Sell the Software.
+
+For purposes of the foregoing, "Sell" means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software.
+
+Any license notice or attribution required by the License must also include this Commons Clause License Condition notice.
+
+---
+
+MIT License
+
+Copyright (c) 2024 James Knight
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+
+---
+
+Contribution License Agreement
+
+By submitting a pull request or contribution to this project, you agree:
+1. Your contributions will be licensed under the same terms as above
+2. You have the right to license your contribution under these terms
+3. You understand that the Commons Clause restrictions apply to derivative works