About My Music

My Music is a fully functional single-page music player built with Next.js 16, React 19, TypeScript, and Tailwind CSS v4. Users can browse a track library, search by title / artist / album, play audio with a custom player, and navigate between tracks with smooth cross-faded background art.

The admin panel supports uploading new tracks with automatic iTunes metadata lookup, cover art download, audio duration detection, and in-place editing of track metadata and audio files — all behind a server-only API layer.

Every line of this project was written through opencode, an AI-native CLI tool that works inside your terminal alongside your existing git workflow. Rather than generating one-shot code and walking away, opencode engages in an iterative conversation — proposing plans, refining them with your feedback, implementing, testing, and committing.

The development cycle (commit & push):

opencode@workspace:~$ plan▊

Quality is enforced at every step of the opencode workflow, not checked after the fact:

• Test-before-commit — the project requires a unit test for every source change, and all tests must pass before a commit is created. This is codified in the project rules (AGENTS.md) so every session follows the same standard.
• TypeScript throughout— every component, hook, and API route is fully typed. No loose objects, no implicit anys.
• ESLint + strict config— eslint-config-next with core-web-vitals and TypeScript rules catches issues at lint time.
• Existing-pattern awareness— opencode reads the surrounding code before writing anything, matching conventions, import styles, and naming rather than inserting foreign patterns.
• Architecture documentation— AGENTS.md contains a living description of the project architecture, commands, and conventions that opencode reads at the start of every session, ensuring consistency across sessions.

opencode is designed to give you fine-grained control over what it can access. Every tool call runs through a permission layer that you configure:

• Project ring-fencing— by default, opencode prompts for approval before touching files outside the working directory (external_directorydefaults to “ask”). You can allow specific external paths and deny others.
• Per-tool permissions— each tool (read, edit, bash, grep, webfetch, etc.) can be set to “allow”, “ask”, or “deny”. Bash commands support pattern rules (git * allowed, rm * denied).
• Doom-loop detection— if the same tool call repeats three times with identical input, opencode pauses and asks for approval, preventing runaway automation.
• Secrets protection— .env and .env.* files are blocked from read by default. Only .env.example is readable. This is a built-in rule, not a config option.
• No code storage— opencode does not store your code or context data. All processing runs locally or through direct API calls to your chosen LLM provider. The /share feature is opt-in (manual by default) and disabled entirely for this project via config.
• Ignore-file awareness— grep and glob tools respect .gitignore patterns by default, so build artifacts and dependencies are not searched unless explicitly requested.
• No training on your data— opencode does not use your conversations or code for model training. What reaches your LLM provider depends on which provider you choose and their policy.

These guardrails are enforced at the configuration and runtime level. The one gap is the AGENTS.md workflow rules: instructions like this project’s pre-commit checklist are followed by convention, not hard-enforced sandboxing. opencode follows them because it is instructed to, but there is no mechanism preventing deviation other than the tool-permission layer.