feat: finer-grained implementation types for config- and platform-fulfilled requirements

[jimisola]

Background

`IMPLEMENTATION` currently has two values:

```python
class IMPLEMENTATION(Enum):
IN_CODE = "in-code"
NOT_APPLICABLE = "N/A"
```

`N/A` works as a workaround for requirements fulfilled outside of application code — auto-configuration, YAML properties, platform infrastructure, dependencies that wire behavior automatically. But it is:

1. Undiscoverable — no documentation explains when to use it or what it means beyond "not in code"
2. Too coarse — `N/A` conflates very different situations:
   • A YAML property that sets a port number
   • An auto-configured library that wires authentication on all outbound clients
   • Platform-level redundancy or networking rules
   • A feature intentionally deferred or not implemented yet (draft lifecycle)
3. Misleading in status output — "Not in Code" section doesn't communicate why it's not in code

Proposed new values

Extend `IMPLEMENTATION` with:

Value	Meaning	`@Requirements` needed?	Tests needed?
`in-code`	Implemented via annotatable application code	Yes	Yes (via SVCs)
`configuration`	Fulfilled by application config (e.g. `application.yml`, env vars)	No	Recommended (verify config is effective)
`platform`	Fulfilled by infrastructure, platform, or an auto-configured dependency	No	Optional (verify behavior if testable)
`N/A` (keep)	Not applicable / not implemented (draft, deferred, intentionally out of scope)	No	No (or MVR/review SVC)

`configuration` — example use cases

• "Service shall expose management endpoints on port 8079" → fulfilled by `management.server.port=8079` in config
• "Service shall use structured JSON logging" → fulfilled by a logging config file activated by an environment convention
• "Service shall retry failed requests with backoff" → fulfilled by a `resilience4j:` YAML block

The SVC for a `configuration` requirement should verify the config is effective, not just present — e.g. an integration test that confirms the endpoint actually responds on that port.

`platform` — example use cases

• "Service shall use service-to-service authentication for outbound calls" → fulfilled by a library that auto-wires auth on all HTTP clients (no application method to annotate)
• "Service shall have distributed tracing" → fulfilled by an OTel auto-configuration starter
• "System shall be highly available" → fulfilled by platform-level load balancing (not testable via application tests)

For testable platform requirements, the SVC can still use `verification: automated-test` with `@SVCs`-annotated tests. For non-testable ones, `verification: platform` or `verification: review` continues to work as today.

Option C: SVC-only completion (related)

A requirement with `implementation: configuration` or `implementation: platform` that has at least one passing SVC should be considered complete — regardless of `@Requirements` annotation count. This is already how `N/A` behaves today; formalizing it for the new types makes the model consistent.

Status display

Suggested grouping in status output:

```
In Code: 45/50 (90%)
Configuration: 3/3 (100%)
Platform: 5/5 (100%)
N/A: 0/0
─────────────────────────
Total: 53/58 (91%)
```

Migration / backwards compat

• `N/A` remains valid — no breaking change
• `in-code` remains the default when `implementation` is omitted
• New values are additive

Related

• The workaround today is `implementation: N/A` — which works but is undiscoverable
• `verification: platform` on SVCs partially addresses this from the SVC side, but doesn't communicate why the requirement has no code implementation

[jimisola]

Documentation gap

Regardless of which new values are added, the existing N/A value needs better documentation. Currently there is no guidance on:

• When to use N/A vs in-code
• What N/A means in terms of SVC requirements (SVCs still required, @Requirements not)
• How N/A appears in status output and what "Not in Code" means

This is a discoverability problem — users working with requirements that have no annotatable code today reach for implementation: N/A only if they happen to read the source or stumble across it. Any new values (configuration, platform) should be documented in the same pass.

[jimisola]

Once the new implementation types are added, the reqstool-ai tooling (MCP skills, AI-assisted requirement authoring) should also be updated to:

• Suggest the correct implementation value when creating or reviewing requirements
• Understand that configuration and platform requirements do not need @Requirements annotations
• Guide users toward the right type based on how the requirement is fulfilled (e.g. detected YAML config → suggest configuration, detected auto-configured dependency → suggest platform)

[jimisola]

There may also be a need for a framework type, to distinguish between the three non-code fulfillment layers:

Value	Fulfilled by	Example
configuration	Application config (YAML, env vars)	management.server.port=8079
framework	Framework auto-configuration or convention	Spring Boot starter that wires security, tracing, actuator
platform	Infrastructure / platform layer	Kubernetes, EKS, load balancing, network policies

framework sits between configuration (something the developer explicitly writes) and platform (something ops/infra owns). A Spring Boot starter that auto-wires authentication on all outbound HTTP clients is not a YAML property the developer sets, but it is also not a Kubernetes concern — it lives in the framework layer.