dave
cdc6bb33d3
Completes 109 of 121 tasks. Every remaining task needs a tenant connection
(T055, T056, T101-T103) or an Azure Automation account (T115-T121).
354 offline Pester tests PASS
Engine purity (Principle IV) PASS
Sanitization (SC-013) PASS (156 files)
Graph module loaded in tests none (SC-008 holds)
What landed
- Four-layer configuration validation with stable finding codes, covering
every VR-002 and VR-003 condition, plus a 23-fixture invalid-config corpus
- Run loop, audit records (NDJSON through a single sink), summaries,
reconciliation, and exit codes 0-6
- Persistence behind a single write-body builder whose result always has
exactly one key
- Invoke-PersonaEngine.ps1 and Edit-PersonaEngineConfig.ps1
- Six docs, two pipelines, traceability matrix, V-5a and sanitization records
Three deviations from tasks.md, each recorded in its status block
T033 is not in Resolve-UserPersona. evaluationErrorThreshold is run-level
state and the rule engine is pure; a counter there would break Principle IV.
It lives in New-PersonaRunCounter and is applied in the run loop.
A new src/Engine/ layer holds Invoke-PersonaEngineRun. The entry script
imports the manifest, which requires Microsoft.Graph.Authentication, so a
loop living only inside it could not run on a machine without the Graph SDK
and SC-004 could not be proven at all. The entry script is now a thin
wrapper and what ships is what is tested.
The invalid-config corpus is generated by a committed script, with the
generated fixtures committed too, so a reviewer sees the fixture in the diff.
Defects found by running the code, not by reading it
Group and role ID lists were double-wrapped: @(Get-PersonaGroupIdPage ...)
around a comma-returned array collapsed every membership list into one
bogus space-joined entry. That is a silent false non-match, exactly what
FR-013 exists to prevent.
A 403 whose status appears only in the exception message parsed as $null,
which the retry policy treats as a transport error - five requests per
account against a tenant already refusing. Status extraction now falls back
to the message text, bounded to 400-599.
The sanitization scan walked tracked files only, so it covered 34 of 156
files and none of this phase's code. It now scans untracked non-ignored
files too, and a negative control confirms it catches a planted leak.
Test-Json reports one error per violating location, not first-failure-only
as the V-5a draft claimed. Record and pin corrected.
Enforcement remains blocked on the V-4 security sign-off.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
69 lines
1.4 KiB
JSON
69 lines
1.4 KiB
JSON
{
|
|
"configVersion": "1.0.0",
|
|
"engine": {
|
|
"targetAttribute": "department",
|
|
"maxConditionDepth": 5,
|
|
"approvedWritableAttributes": [
|
|
"department"
|
|
],
|
|
"defaultMembershipMode": "direct",
|
|
"summaryInterval": 25
|
|
},
|
|
"personas": [
|
|
"Employee",
|
|
"Guest",
|
|
"Tier0-Admin"
|
|
],
|
|
"dataSources": {
|
|
"groups": {
|
|
"enabled": true
|
|
},
|
|
"roles": {
|
|
"enabled": true
|
|
}
|
|
},
|
|
"logging": {
|
|
"destination": "stream",
|
|
"traceConditionValues": false
|
|
},
|
|
"rules": [
|
|
{
|
|
"id": "RULE-0010-GUEST",
|
|
"persona": "Guest",
|
|
"description": "Accounts whose user type is Guest.",
|
|
"match": {
|
|
"operator": "all",
|
|
"conditions": [
|
|
{
|
|
"operator": "equals",
|
|
"type": "property",
|
|
"property": "UserType",
|
|
"value": "Guest"
|
|
}
|
|
]
|
|
},
|
|
"priority": 10,
|
|
"enabled": true,
|
|
"name": "Guest accounts"
|
|
},
|
|
{
|
|
"id": "RULE-0900-EMPLOYEE",
|
|
"persona": "Employee",
|
|
"description": "Default classification for member accounts.",
|
|
"match": {
|
|
"operator": "all",
|
|
"conditions": [
|
|
{
|
|
"operator": "isNotNull",
|
|
"type": "property",
|
|
"property": "Department"
|
|
}
|
|
]
|
|
},
|
|
"priority": 900,
|
|
"enabled": true,
|
|
"name": "Employees"
|
|
}
|
|
]
|
|
}
|