Developer staffing guide · 8 minute read ·
Make feature flag targeting rules disagree on purpose — September 11 review
Verify which rule wins when identity, group, percentage, and default targeting overlap.
Readiness check
Is the handoff ready?
Use this table before you send the first ticket. Fix the weak spots while access is still limited.
| Area | Ready | Needs work |
|---|---|---|
| Question | One observable feature flag precedence outcome | A request to inspect the whole system |
| Fixture | synthetic identities that match no rule, one rule, several rules, a percentage split, and a stale rule set | Customer data or shared credentials |
| Evidence | identity label, rule version, matching rules, evaluation order, returned variation, cache age, and reason | A pass label without observed values |
| Approval | Product and release owners choose targeting intent, exposure, kill switch, and production timing. | The contractor changes production alone |
Reproduce the feature flag precedence failure safely
Two targeting rules match the same identity and different services evaluate them in a different order. Start with one case that can fail without touching customer records or production infrastructure. Write the expected result, stop condition, and reviewer beside the fixture.
Use synthetic identities that match no rule, one rule, several rules, a percentage split, and a stale rule set. Label every identity and artifact so a reviewer can distinguish test evidence from a live record.
Leave enough evidence for a second person — September 11 review
Capture identity label, rule version, matching rules, evaluation order, returned variation, cache age, and reason. Include the source revision and test time. If behavior changes between runs, retain both results.
Product and release owners choose targeting intent, exposure, kill switch, and production timing. A remote programmer can prepare the fixture, run bounded checks, and explain the result. New policy, privileged access, and release approval stay with the named owner.
Copy-ready brief
Paste this into your hiring request
Test one bounded feature flag precedence case against written acceptance rules.
synthetic identities that match no rule, one rule, several rules, a percentage split, and a stale rule set
Record identity label, rule version, matching rules, evaluation order, returned variation, cache age, and reason.
Product and release owners choose targeting intent, exposure, kill switch, and production timing.
Buyer questions
Questions about planning the role
What should the first run prove?
It should show the expected feature flag precedence result for one controlled fixture.
What belongs in the handoff?
Include identity label, rule version, matching rules, evaluation order, returned variation, cache age, and reason, the source revision, and any untested condition.
Who approves a production change?
Product and release owners choose targeting intent, exposure, kill switch, and production timing.
Sources
Planning references
These links explain the security, code review, and worker classification points used in this guide.
- NIST Secure Software Development FrameworkNIST guidance for managing software development risk.
- GitHub pull request reviewsFirst-party documentation for review and approval.