Security remediation — field guides

The distinct field guides record for Security remediation. This page is proposal-only.

Status: proposedLifecycle: candidate

Record status

Record ID: project:security-remediation
Parent lifecycle: candidate
Page lane: app_features
Lane lifecycle: proposed
Owner: Not separately recorded
Owner role: Not separately recorded
Owner status: Not separately recorded
Qualification result: NOT RUN · held for evidence and human review

Working browser surface: Project templates & workflows — overview — Create a local project from this template and validate its forms. This route is local-only; provider, credential, database, customer, publication, deployment, and production effects remain held.

Related field-guide records

/app/notebook/field-guides/

Source-proposed guide paths are references, not proof that those paths resolve.

Operating sequence

Create the project record from the reported issue and assign a project owner.
Complete intake and attach source-labelled references; do not treat an unverified report as a confirmed vulnerability.
Define scope, exclusions, authority limits, and stop-work conditions.
Create milestones for investigation, repair, validation, approval, and closure.
Enter target deadlines and generate a visible workback using Notebook to-dos and Agenda draft views.
Record dependencies and assign owners, backups, and handoff dates.
Select only bounded tools, guides, records, or providers whose exact identity and purpose are recorded; keep unavailable or external effects held.
Investigate and capture reproducible evidence with source locators, revisions, and redaction state.
Propose the repair and record its expected impact, rollback plan, and validation method.
Obtain the required human approval before any action outside the approved scope or before closure.
Validate the repair against deterministic acceptance tests and record failures or inconclusive results.
Review residual risks, unresolved dependencies, evidence completeness, and follow-up work.
Close only when the closure approval is recorded; otherwise mark the project held or reopened.

Handoff boundary

Treating a reported issue as confirmed without reproducible evidence.
Expanding investigation or repair beyond the approved scope.
Exposing secrets, personal data, customer data, or protected evidence in notes, attachments, messages, or public surfaces.
Performing production, provider, credential, database, customer, publication, or external communication effects without separate verification and approval.
Using a deadline or workback as proof that work occurred.
Closing on the basis of an unreviewed test, incomplete evidence, or unsupported claim.
Losing provenance, source locators, hashes, revisions, redaction state, or custody information.
Silent rescheduling, hidden automation, duplicate projects, or conflicting owners.
Marking a risk accepted without naming the acceptance owner and residual risk.
Inaccessible forms that hide validation errors, status, dependencies, or approval conditions.

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

source_record:project:security-remediation
NotebookCollectionKind.project
NotebookTodoPayload.dueAt
Notebook Agenda deadlines/workbacks
Observed native contract: records preserve canonical IDs, provenance, revisions, lifecycle, tags, links, attachments, and record revisions
Observed native contract: PointGuard is a persistent cross-app context surface; specialist apps remain execution and canonical-record owners
Observed native contract: provider, credential, database, customer, publication, and production effects are held
/app/notebook/projects/
/app/notebook/to-dos/
/app/notebook/agenda/
/app/notebook/approvals/
/app/notebook/files/
/app/notebook/field-guides/
/app/notebook/agent-logs/
/app/pointguard/
Notebook records provenance and revision contract
PointGuard persistent cross-app context surface
Current GuthHub app routes and held web boundary
ALLOWED_INSTRUMENTS: checksum-verifier