Refactor repo for standalone portable provider workflow

AGENTS.md

@@ -1,67 +1,58 @@
 # AGENTS.md
 
 ## Goal
-Build a Terraform provider for Dynu DNS and domains.
+Build and maintain a standalone Terraform provider for Dynu DNS and domains.
 
-## Scope for current phase
-Read-only only. Implement provider configuration and data sources first.
-Do not implement any writable Terraform resources in the first phase.
+## Scope
+Current phase is **read-only**.
 
-## Language and framework
-- Language: Go
-- Terraform provider framework: HashiCorp Terraform Plugin Framework
-- Do not use the legacy SDK unless explicitly requested.
-
-## API usage
-- Use Dynu's public API.
-- Prefer stable, documented endpoints.
-- Build a small internal API client package rather than scattering HTTP calls across resources/data sources.
-- Add clear handling for pagination, 4xx/5xx responses, and malformed responses.
-- Never log secrets.
-
-## Provider design
 Implement:
 - Provider configuration
 - Environment variable support for credentials
 - Read-only data sources:
-  - dynu_domains
-  - dynu_domain
-  - dynu_dns_records
+  - `dynu_domains`
+  - `dynu_domain`
+  - `dynu_dns_records`
 
-Do not implement:
-- resource_dynu_dns_record
-- any create/update/delete flows
-- any speculative unsupported resources
+Do not implement in this phase:
+- Any Terraform resources with create/update/delete
+- Any write HTTP methods
 
-## Safety
-- Read-only phase only.
-- No write HTTP methods in this phase.
-- Acceptance tests must only cover provider auth and read-only data sources.
-- Any future write support must be added in a separate phase.
+## Language and framework
+- Language: Go
+- Framework: HashiCorp Terraform Plugin Framework
+- Do not use the legacy Terraform Plugin SDK unless explicitly requested
 
-## Code quality
-- Keep code modular and idiomatic Go.
-- Use strong typing for API models.
-- Prefer explicit schema definitions with clear descriptions.
-- Return actionable diagnostics.
-- Keep public documentation accurate to actual implementation.
+## API usage
+- Use Dynu public API endpoints
+- Prefer stable, documented endpoints
+- Keep HTTP logic in a small internal client package
+- Handle pagination and API errors clearly
+- Never log secrets or credentials
+
+## Portability requirements
+- Keep the repository generic and standalone
+- Do not reference personal infrastructure, private domains, homelab tooling, or external repo scripts
+- Use neutral placeholders in docs and examples (for example: `example.com`, `my-test-domain.example`, `var.dynu_api_key`)
+- Avoid hardcoded local filesystem paths
 
 ## Testing
-- Add unit tests where practical.
-- Add acceptance tests gated behind environment variables.
-- Do not require live credentials for normal unit tests.
+- Add unit tests where practical
+- Gate acceptance tests behind generic environment variables
+  - `TF_ACC=1`
+  - `DYNU_API_KEY`
+  - optional `DYNU_DOMAIN` for domain-specific acceptance coverage
+- Unit tests must not require live credentials
 
 ## Documentation
-- Add examples for every implemented data source.
-- Update README with provider configuration and environment variables.
-- Document limitations and unsupported areas clearly.
+- Keep README and examples aligned with actual provider behavior
+- Document current read-only limitations clearly
+- Include build, test, and acceptance test instructions for any contributor
+
+## Developer scripts
+- `scripts/setup-dev.sh`: validate local toolchain requirements
+- `scripts/check.sh`: run formatting and unit checks
+- `scripts/testacc.sh`: run acceptance tests using generic env vars
 
 ## Output expectations
-Create a provider skeleton that can compile and expose the provider plus read-only data sources.
-
-## Codex environment
-- Use `codex/setup.sh` to prepare the repository-local Codex environment.
-- Use `codex/maintain.sh` to refresh and validate the environment.
-- Use `codex/doctor.sh` for troubleshooting.
-- Do not install global packages unless explicitly required.
-- Prefer repo-local state under `.codex/`.
+Changes should keep the provider idiomatic, easy to contribute to, and ready for public/open-source usage.