# Environment Safety
- **PATH Prioritization**: Upon initialization, check if `/usr/lib/Goose/resources/bin` is at the very start of your PATH. To prevent internal tool leakage into project builds:
    1. Move the Goose resource path to the **end** of the PATH: `export PATH=$(echo $PATH | sed -e 's|/usr/lib/Goose/resources/bin:||'):/usr/lib/Goose/resources/bin`.
    2. Verify `which node` now points to your system or version-managed Node.
- **Verification**: This ensures that `npm run test` and `npm run lint`  use the project's intended environment while keeping Goose's internal binaries available as a fallback.

Before writing any code, you must read `eslint.config.mts` and `AGENTS.md`. Treat these not as suggestions, but as hard technical constraints that define the 'Success Criteria' for this task. If you are about to use any, STOP and define a strict interface instead, as required by the 'Strict type safety' rule.

# Agent Initialization
1. Read `AGENTS.md` for core project architecture and standards.
2. Read `.goose/vault-intelligence-rules.md` for Goose-specific research and planning protocols.
3. Before writing any code, you must read `eslint.config.mts`. Treat it not as suggestions, but as hard technical constraints that define the 'Success Criteria' for this task. If you are about to use `any` type, STOP and define a strict interface instead, as required by the 'Strict type safety' rule. Note the perfectionist rules.

# Research Protocol
- Use the `Analyze` extension to understand service/view relationships.
- Use the `Summarize` extension for deep dives into core logic files.
- Always use `grep` (shell) to verify SDK signatures and service anchors.

# Tests
- The `tests/` directory contains the project test scripts.
- Always consider the impact of any changes to the existing tests. Propose or implement updates as needed.
- Always consider if changes should have new test scripts built for them. Incorporate them into the `npm run test` process.

# Documentation
- We document all code changes in `CHANGELOG.md`; make sure you update it **if needed**, that is, if we have made updates since the last user-facing release. Do not update `CHANGELOG.md` for internal commits that is resolving errors or omissions in the code for features we are working on; the test is: did the user see the problem or omission? If not, no update to `CHANGELOG.md` is needed. 
- Do not delete ANY existing entries outside the 'Unreleased' section, but add yours to the 'Unreleased' section.
- **Always** verify line counts with `wc -l` before and after editing any file over 50 lines and always for `CHANGELOG.md`. If the line count has decreased that is a FAILURE. You MUST show the line counts to the user.


# Final completion
And the end of your implementation phase:

- Always ensure you run all of the commands below in this order and that each one pass without errors or warnings:
    1. `npm run lint`
    2. `npm run build`
    3. `npm run test`
    4. `npm run docs:build`
    5. `npm ci`
- **Zero-Trust Reporting**: Do not report a "Success" status if the tool produced output. You must read and address all linting errors, type mismatches, and warnings. 
- Fix any errors before considering the work done. 
- Make sure you **fix** the error: do not simply hide anything behind linter directives or similar and do not change the eslint configuration just to fix an error (unless that is an explicit part of your instructions).
