Guth
NewsDocs
Page actions
View as Markdown ↗
Explore MCP tools ↗

project template / candidate

Security remediation — forms

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

Status: proposedLifecycle: candidate

Record status

Record ID
project:security-remediation
Parent lifecycle
candidate
Page lane
forms
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.

Proposed form sections

Each section is a candidate schema for inspectable records. Required-field presence does not establish factual truth.

Intake

Define the reported issue, source, urgency, and accountable owner before investigation begins.

  • issue title
  • reported by
  • date reported
  • report source and locator
  • affected asset or record identifier
  • issue description
  • suspected impact
  • confidentiality classification
  • initial severity: low, medium, high, critical
  • requested completion date
  • project owner
  • security owner
  • intake status: draft, needs review, accepted, rejected, held
  • acceptance rationale
  • duplicate or related project IDs

Scope and authority

Set explicit boundaries, exclusions, and permitted actions.

  • in-scope assets, records, routes, or code areas
  • out-of-scope assets and actions
  • authorized investigation actions
  • authorized repair actions
  • actions requiring approval
  • prohibited actions
  • credential and secret handling rule
  • data minimization rule
  • production-effect status: held unless separately approved and verified
  • customer or public visibility status: held
  • scope owner
  • scope approval record ID
  • scope revision and effective date

Milestones

Break the work into ordered, reviewable stages with owners and evidence requirements.

  • milestone ID
  • milestone name
  • milestone purpose
  • owner
  • start date
  • due date
  • entry criteria
  • planned outputs
  • required evidence
  • reviewer
  • approval gate
  • status: not started, active, blocked, complete, held
  • completion note
  • completion date

Deadlines and workback

Create source-bound deadlines and derive a visible workback without hidden automation.

  • target completion date
  • deadline type: investigation, repair, validation, approval, closure
  • timezone
  • priority
  • recurrence candidate
  • workback offset or duration
  • derived due date
  • calendar conflict note
  • deadline owner
  • escalation date
  • deadline status
  • revision reason

Dependencies

Record prerequisites and blockers that can prevent safe progress.

  • dependency ID
  • dependency description
  • dependency type: record, person, access, evidence, review, environment
  • blocking milestone
  • dependency owner
  • needed by date
  • status: unknown, open, ready, blocked, waived
  • external reference or locator
  • waiver approver
  • waiver rationale
  • next check date

Owners and handoffs

Make responsibility explicit for every decision and deliverable.

  • project owner
  • security owner
  • investigator
  • repair owner
  • validation owner
  • approver
  • closure owner
  • backup owner
  • handoff date
  • handoff note
  • authority boundary
  • owner acknowledgement state

Tools and guides

Link only designated interfaces, bounded procedures, and verified instruments needed for the work.

  • tool or guide name
  • kind: interface, skill, guide, record, provider
  • designated purpose
  • route or record reference
  • authority limit
  • version or revision
  • owner
  • selection rationale
  • availability state: proposed, available, held
  • fallback procedure

Evidence

Preserve source-labelled proof of findings, changes, tests, and review without hidden uploads.

  • evidence ID
  • evidence type: observation, reproduction, patch, test, log, screenshot reference, review note
  • description
  • source record ID
  • source locator
  • source SHA-256 if available
  • captured by
  • captured at
  • attachment or local file reference
  • redaction status
  • integrity or reproducibility note
  • linked milestone
  • visibility: private, review, held

Approvals

Gate scope changes, repairs, risk acceptance, and closure through explicit human review.

  • approval ID
  • decision type: scope, repair, exception, risk acceptance, closure
  • proposal summary
  • decision owner
  • reviewer
  • decision: needs review, approved, held
  • decision date
  • conditions
  • receipt or evidence reference
  • authority limitation
  • rejection or hold reason

Risks and failure states

Track harm, uncertainty, rollback readiness, and conditions that require stopping.

  • risk ID
  • risk statement
  • cause
  • affected asset or party
  • likelihood
  • impact
  • risk rating
  • mitigation
  • contingency or rollback plan
  • risk owner
  • trigger condition
  • stop-work condition
  • residual risk
  • acceptance owner
  • status: open, mitigated, accepted, materialized, closed

Closure

Confirm the bounded issue is addressed, evidence is complete, residual risk is explicit, and no unsupported external effect is claimed.

  • closure criteria checklist
  • final finding
  • repair summary
  • validation summary
  • remaining limitations
  • residual risks
  • follow-up actions
  • follow-up owners and due dates
  • linked approval IDs
  • evidence completeness statement
  • record revision summary
  • closure owner
  • closure decision: complete, held, reopened
  • closure date
  • public or customer claim status: held unless separately verified

Accessible state contract

  • Every field requires a visible and programmatic label.
  • Required and optional fields must be stated in text.
  • Invalid entries require an actionable message linked to the field.
  • Blocked and Held states remain visible without relying on color alone.

Supporting documentation fields

These fields come from the app_features lane and remain separate from the primary operating form.

Scope and ownership

Define the bounded issue, responsible human, and authority boundary before investigation begins.

  • project title
  • issue summary
  • human owner
  • reviewer
  • affected surface or record locator
  • in-scope actions
  • explicitly out-of-scope actions
  • authority boundary acknowledgement

Evidence and provenance

Capture only source-labelled evidence and preserve traceability.

  • evidence description
  • source locator
  • source SHA-256 if available
  • record or file link
  • observed date
  • provenance note
  • sensitivity label
  • evidence confidence

Remediation plan

Turn the issue into reviewable steps with dependencies, owners, and deadlines.

  • remediation objective
  • step title
  • step owner
  • dependency
  • priority
  • due date
  • estimated effort
  • completion state
  • rollback or containment note
  • review required

Validation and approval

Record tests, unresolved risk, reviewer disposition, and held effects.

  • validation method
  • expected result
  • observed result
  • test status
  • residual risk
  • approval status
  • reviewer note
  • receipt or revision link
  • external effect requested
  • hold reason

Required or proposed record references

No record existence is asserted by this documentation page.

  • project record
  • intake record
  • scope record
  • milestone records
  • deadline and workback to-dos
  • dependency records
  • owner assignments
  • tool and guide links
  • evidence records
  • approval records
  • risk records
  • closure record
  • source-labelled file references
  • security issue note
  • source-labelled evidence references
  • remediation to-dos
  • deadline and workback records
  • approval record
  • agent log or investigation receipt
  • linked file references

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