📌 Description
src/pii/policy.ts defines a TRUST_BOUNDARIES array describing what each actor class (Anonymous, Partner, Administrator, Internal Worker) may and may not do. The GET /api/privacy route in src/routes/privacy.ts currently returns field policies and retention rules but does not include the trust boundaries. Including them would make the privacy endpoint a comprehensive machine-readable policy document for data-controller integrations and privacy audits.
💡 Why it matters: Exposing the trust boundary model at /api/privacy enables automated compliance checks to verify that the declared access model matches the actual middleware configuration.
🧩 Requirements and context
- Add
trustBoundaries: TRUST_BOUNDARIES to the response body of GET /api/privacy
- Update the OpenAPI schema in
src/openapi/spec.ts to include a TrustBoundary[] schema
- The
denied and allowed arrays must be string arrays (already the case in the type)
- Update
tests/routes/privacy.test.ts to assert the new field is present and matches the policy module
- Do not include any internal implementation details in the
allowed/denied strings
Non-functional requirements
- Must be secure, tested, and documented.
- Should be efficient and easy to review.
🛠️ Suggested execution
1. Fork the repo and create a branch
git checkout -b feat/privacy-trust-boundaries
2. Implement changes
- Write/modify the relevant source:
src/routes/privacy.ts, src/openapi/spec.ts
- Write comprehensive tests:
tests/routes/privacy.test.ts
- Add documentation: OpenAPI schema for
TrustBoundary
- Include TSDoc on the
GET /api/privacy handler update
- Validate security assumptions: none of the
allowed/denied strings must reference internal hostnames, IPs, or connection details
3. Test and commit
npm test -- --testPathPattern=privacy
- Cover edge cases: trust boundaries array is not empty, each entry has
actor, allowed, denied fields
- Include test output and security notes in the PR description.
Example commit message
feat(privacy): include TRUST_BOUNDARIES in GET /api/privacy response
✅ Acceptance criteria
🔒 Security notes
The denied arrays must not hint at internal bypass mechanisms or undocumented admin override paths. Review each entry's strings before merging.
📋 Guidelines
- Minimum 95% test coverage
- Clear documentation
- Timeframe: 96 hours
📌 Description
src/pii/policy.tsdefines aTRUST_BOUNDARIESarray describing what each actor class (Anonymous, Partner, Administrator, Internal Worker) may and may not do. TheGET /api/privacyroute insrc/routes/privacy.tscurrently returns field policies and retention rules but does not include the trust boundaries. Including them would make the privacy endpoint a comprehensive machine-readable policy document for data-controller integrations and privacy audits.🧩 Requirements and context
trustBoundaries: TRUST_BOUNDARIESto the response body ofGET /api/privacysrc/openapi/spec.tsto include aTrustBoundary[]schemadeniedandallowedarrays must be string arrays (already the case in the type)tests/routes/privacy.test.tsto assert the new field is present and matches the policy moduleallowed/deniedstringsNon-functional requirements
🛠️ Suggested execution
1. Fork the repo and create a branch
2. Implement changes
src/routes/privacy.ts,src/openapi/spec.tstests/routes/privacy.test.tsTrustBoundaryGET /api/privacyhandler updateallowed/deniedstrings must reference internal hostnames, IPs, or connection details3. Test and commit
npm test -- --testPathPattern=privacyactor,allowed,deniedfieldsExample commit message
✅ Acceptance criteria
GET /api/privacyresponse includestrustBoundarieskeytrustBoundariesarray matchesTRUST_BOUNDARIESfromsrc/pii/policy.tsTrustBoundarytypetrustBoundaries🔒 Security notes
The
deniedarrays must not hint at internal bypass mechanisms or undocumented admin override paths. Review each entry's strings before merging.📋 Guidelines