lsd-pi 1.0.0 → 1.1.0

package/dist/resources/extensions/gsd/templates/project.md

@@ -1,31 +0,0 @@
-# Project
-
-## What This Is
-
-{{whatTheProjectDoes — plain language, current state, not aspirational}}
-
-## Core Value
-
-<!-- This is the primary value anchor for prioritization and tradeoffs.
-     If scope must shrink, this should survive. -->
-
-{{theOneThingThatMustWorkEvenIfEverythingElseIsCut}}
-
-## Current State
-
-{{whatHasBeenBuiltSoFar — what works, what exists, what's deployed}}
-
-## Architecture / Key Patterns
-
-{{howItsStructured — conventions, tech stack, key modules, established patterns}}
-
-## Capability Contract
-
-See `.gsd/REQUIREMENTS.md` for the explicit capability contract, requirement status, and coverage mapping.
-
-## Milestone Sequence
-
-<!-- Check off milestones as they complete. One-liners should describe intent, not implementation detail. -->
-
-- [ ] M001: {{title}} — {{oneLiner}}
-- [ ] M002: {{title}} — {{oneLiner}}

package/dist/resources/extensions/gsd/templates/reassessment.md

@@ -1,29 +0,0 @@
----
-date: {{YYYY-MM-DD}}
-triggering_slice: {{milestoneId/sliceId}}
-verdict: {{no-change | modified}}
----
-
-# Reassessment: {{triggering_slice}}
-
-## Changes Made
-
-<!-- For "no-change" verdict: 1-2 sentences confirming the roadmap still holds. Keep it brief.
-     For "modified" verdict: list which slices changed (reordered, merged, split, added, removed) and why.
-     Don't restate what the slice built — the slice summary covers that. Focus on what changed in the plan. -->
-
-{{placeholder}}
-
-## Requirement Coverage Impact
-
-<!-- Which requirements were added, removed, deferred, or reordered.
-     Write "None." if no requirements were affected. -->
-
-{{placeholder}}
-
-## Decision References
-
-<!-- D-numbers from DECISIONS.md that informed or resulted from this reassessment.
-     Write "None." if no recorded decisions apply. -->
-
-{{placeholder}}

package/dist/resources/extensions/gsd/templates/requirements.md

@@ -1,81 +0,0 @@
-# Requirements
-
-This file is the explicit capability and coverage contract for the project.
-
-Use it to track what is actively in scope, what has been validated by completed work, what is intentionally deferred, and what is explicitly out of scope.
-
-Guidelines:
-- Keep requirements capability-oriented, not a giant feature wishlist.
-- Requirements should be atomic, testable, and stated in plain language.
-- Every **Active** requirement should be mapped to a slice, deferred, blocked with reason, or moved out of scope.
-- Each requirement should have one accountable primary owner and may have supporting slices.
-- Research may suggest requirements, but research does not silently make them binding.
-- Validation means the requirement was actually proven by completed work and verification, not just discussed.
-
-## Active
-
-### R001 — {{requirementTitle}}
-- Class: {{core-capability | primary-user-loop | launchability | continuity | failure-visibility | integration | quality-attribute | operability | admin/support | compliance/security | differentiator | constraint | anti-feature}}
-- Status: active
-- Description: {{what must be true in plain language}}
-- Why it matters: {{why this matters to actual product usefulness/completeness}}
-- Source: {{user | inferred | research | execution}}
-- Primary owning slice: {{M001/S01 | none yet}}
-- Supporting slices: {{M001/S02, M001/S03 | none}}
-- Validation: {{unmapped | mapped | partial | validated}}
-- Notes: {{constraints / acceptance nuance / why not yet validated}}
-
-## Validated
-
-### R010 — {{requirementTitle}}
-- Class: {{failure-visibility}}
-- Status: validated
-- Description: {{what was proven}}
-- Why it matters: {{why it matters}}
-- Source: {{user | inferred | research | execution}}
-- Primary owning slice: {{M001/S01}}
-- Supporting slices: {{none}}
-- Validation: validated
-- Notes: {{what verification proved this}}
-
-## Deferred
-
-### R020 — {{requirementTitle}}
-- Class: {{admin/support}}
-- Status: deferred
-- Description: {{useful later, not now}}
-- Why it matters: {{why it might matter later}}
-- Source: {{user | inferred | research | execution}}
-- Primary owning slice: {{none}}
-- Supporting slices: {{none}}
-- Validation: unmapped
-- Notes: {{why deferred now}}
-
-## Out of Scope
-
-### R030 — {{requirementTitle}}
-- Class: {{anti-feature | constraint | core-capability}}
-- Status: out-of-scope
-- Description: {{what is explicitly excluded}}
-- Why it matters: {{what scope confusion this prevents}}
-- Source: {{user | inferred | research | execution}}
-- Primary owning slice: {{none}}
-- Supporting slices: {{none}}
-- Validation: n/a
-- Notes: {{why excluded}}
-
-## Traceability
-
-| ID | Class | Status | Primary owner | Supporting | Proof |
-|---|---|---|---|---|---|
-| R001 | primary-user-loop | active | M001/S01 | none | mapped |
-| R010 | failure-visibility | validated | M001/S01 | none | validated |
-| R020 | admin/support | deferred | none | none | unmapped |
-| R030 | anti-feature | out-of-scope | none | none | n/a |
-
-## Coverage Summary
-
-- Active requirements: {{count}}
-- Mapped to slices: {{count}}
-- Validated: {{count}}
-- Unmapped active requirements: {{count}}

package/dist/resources/extensions/gsd/templates/research.md

@@ -1,79 +0,0 @@
-# {{scope}} — Research
-
-**Date:** {{date}}
-
-<!-- Required sections: Summary, Recommendation, Implementation Landscape.
-     All other sections: include only when they have real content.
-     For light research (straightforward work with known patterns),
-     the required sections alone are sufficient. -->
-
-## Summary
-
-{{summary — 2-3 paragraphs with primary recommendation}}
-
-## Recommendation
-
-{{whatApproachToTake_AND_why}}
-
-## Implementation Landscape
-
-<!-- This section is the primary input for the planner agent.
-     Be specific — file paths, function names, patterns to follow.
-     The planner uses this to scope tasks to files and decide build order. -->
-
-### Key Files
-
-- `{{filePath}}` — {{whatItDoesAndHowItRelates}}
-- `{{filePath}}` — {{whatNeedsToChange}}
-
-### Build Order
-
-{{whatToProveOrBuildFirst_AND_why — whatUnblocksDownstreamWork}}
-
-### Verification Approach
-
-{{howToConfirmTheSliceWorks — commands, tests, observable behaviors}}
-
-<!-- Sections below: include when applicable, omit entirely when not. -->
-
-## Don't Hand-Roll
-
-<!-- Include when existing libraries/tools solve problems the slice would otherwise reimplement. -->
-
-| Problem | Existing Solution | Why Use It |
-|---------|------------------|------------|
-| {{problem}} | {{solution}} | {{why}} |
-
-## Constraints
-
-<!-- Include when the codebase, runtime, or dependencies impose hard limits on approach. -->
-
-- {{hardConstraintFromCodebaseOrRuntime}}
-- {{constraintFromDependencies}}
-
-## Common Pitfalls
-
-<!-- Include when there are non-obvious failure modes worth flagging. -->
-
-- **{{pitfall}}** — {{howToAvoid}}
-- **{{pitfall}}** — {{howToAvoid}}
-
-## Open Risks
-
-<!-- Include when execution could hit unknowns that affect the plan. -->
-
-- {{riskThatCouldSurfaceDuringExecution}}
-
-## Skills Discovered
-
-<!-- Include when skill discovery found relevant skills. -->
-
-| Technology | Skill | Status |
-|------------|-------|--------|
-| {{technology}} | {{owner/repo@skill}} | {{installed / available / none found}} |
-
-## Sources
-
-<!-- Include when external docs, articles, or references informed the research. -->
-
-- {{whatWasLearned}} (source: [{{title}}]({{url}}))

package/dist/resources/extensions/gsd/templates/roadmap.md

@@ -1,131 +0,0 @@
-# {{milestoneId}}: {{milestoneTitle}}
-
-**Vision:** {{vision}}
-
-## Success Criteria
-
-<!-- Write success criteria as observable truths, not implementation tasks.
-     Prefer user-visible or runtime-visible outcomes that can be re-checked at
-     milestone completion.
-
-     Good:
-     - "User can complete the full import flow end-to-end"
-     - "The daemon reconnects automatically after restart"
-
-     Bad:
-     - "Add import API and UI"
-     - "Refactor reconnect logic" -->
-
-- {{criterion}}
-- {{criterion}}
-
-## Key Risks / Unknowns
-
-<!-- List the real risks and uncertainties that shape how slices are ordered.
-     If the project is straightforward, this section can be short or empty.
-     Don't invent risks — only list things that could actually invalidate downstream work. -->
-
-- {{risk}} — {{whyItMatters}}
-- {{risk}} — {{whyItMatters}}
-
-## Proof Strategy
-
-<!-- For each real risk above, name which slice retires it and what "proven" looks like.
-     Proof comes from building the real thing, not from spikes or research.
-     Skip this section for straightforward projects with no major unknowns. -->
-
-- {{riskOrUnknown}} → retire in {{sliceId}} by proving {{whatWillBeProven}}
-- {{riskOrUnknown}} → retire in {{sliceId}} by proving {{whatWillBeProven}}
-
-## Verification Classes
-
-- Contract verification: {{tests / shell verifiers / fixtures / artifact checks}}
-- Integration verification: {{real subsystem interaction that must be exercised, or none}}
-- Operational verification: {{service lifecycle / restart / reconnect / supervision / deploy-install behavior, or none}}
-- UAT / human verification: {{what needs real human judgment, or none}}
-
-## Milestone Definition of Done
-
-This milestone is complete only when all are true:
-
-- {{all slice deliverables are complete}}
-- {{shared components are actually wired together}}
-- {{the real entrypoint exists and is exercised}}
-- {{success criteria are re-checked against live behavior, not just artifacts}}
-- {{final integrated acceptance scenarios pass}}
-
-## Requirement Coverage
-
-- Covers: {{R001, R002}}
-- Partially covers: {{R003 or none}}
-- Leaves for later: {{R004 or none}}
-- Orphan risks: {{none or what is still unmapped}}
-
-## Slices
-
-- [ ] **S01: {{sliceTitle}}** `risk:high` `depends:[]`
-  > After this: {{whatIsDemoableWhenThisSliceIsDone}}
-- [ ] **S02: {{sliceTitle}}** `risk:medium` `depends:[S01]`
-  > After this: {{whatIsDemoableWhenThisSliceIsDone}}
-- [ ] **S03: {{sliceTitle}}** `risk:low` `depends:[S01]`
-  > After this: {{whatIsDemoableWhenThisSliceIsDone}}
-
-<!--
-  Format rules (parsers depend on this exact structure):
-  - Checkbox line: - [ ] **S01: Title** `risk:high|medium|low` `depends:[S01,S02]`
-  - Demo line:     >  After this: one sentence showing what's demoable
-  - Mark done:     change [ ] to [x]
-  - Order slices by risk (highest first)
-  - Each slice must be a vertical, demoable increment — not a layer
-  - If all slices are completed exactly as written, the milestone's promised outcome should actually work at the stated proof level
-  - depends:[X,Y] means X and Y must be done before this slice starts
-
-  Planning quality rules:
-  - Every slice must ship real, working, demoable code — no research-only or foundation-only slices
-  - Early slices should prove the hardest thing works by building through the uncertain path
-  - Each slice should establish a stable surface that downstream slices can depend on
-  - Demo lines should describe concrete, verifiable evidence — not vague claims
-  - In brownfield projects, ground slices in existing modules and patterns
-  - If a slice doesn't produce something testable end-to-end, it's probably a layer — restructure it
-  - If the milestone crosses multiple runtime boundaries (for example daemon + API + UI, bot + subprocess + service manager, or extension + RPC + filesystem), include an explicit final integration slice that proves the assembled system works end-to-end in a real environment
-  - Contract or fixture proof does not replace final assembly proof when the user-visible outcome depends on live wiring
-  - Each "After this" line must be truthful about proof level: if only fixtures or tests prove it, say so; do not imply the user can already perform the live end-to-end behavior unless that has actually been exercised
--->
-
-## Horizontal Checklist
-
-<!-- Cross-cutting concerns across all slices. Check each that was considered.
-     OMIT ENTIRELY for trivial milestones. -->
-
-- [ ] Every active R### re-read against new code — still fully satisfied?
-- [ ] Every D### from prior milestones re-evaluated — still valid at new scope?
-- [ ] Graceful shutdown / cleanup on termination verified
-- [ ] Revenue / billing path impact assessed (or N/A)
-- [ ] Auth boundary documented — what's protected vs public
-- [ ] Shared resource budget confirmed — connection pools, caches, rate limits hold under peak
-- [ ] Reconnection / retry strategy verified for every external dependency
-
-## Boundary Map
-
-<!-- Be specific. Name concrete outputs: API endpoints, event payloads, shared types/interfaces,
-     persisted record shapes, CLI contracts, file formats, or invariants.
-     "Produces: auth system" is too vague. "Produces: session middleware that attaches
-     authenticated user to request context" is useful.
-     Consumes should name what downstream slices assume is already available and stable.
-     If the project has a test framework, boundary contracts should ideally be exercised by tests. -->
-
-### S01 → S02
-
-Produces:
-- {{concreteOutput — API, type, data shape, interface, or invariant}}
-
-Consumes:
-- nothing (first slice)
-
-### S01 → S03
-
-Produces:
-- {{concreteOutput — API, type, data shape, interface, or invariant}}
-
-Consumes:
-- nothing (first slice)

package/dist/resources/extensions/gsd/templates/runtime.md

@@ -1,21 +0,0 @@
-# Runtime Context
-
-## Stack
-- **Language:** (e.g., TypeScript, Python, Go)
-- **Framework:** (e.g., Next.js, FastAPI, Gin)
-- **Build:** (e.g., npm run build, cargo build)
-- **Test:** (e.g., npm run test, pytest)
-- **Lint:** (e.g., npm run lint, ruff check)
-
-## Environment
-- **Node version:** (e.g., 20.x)
-- **Package manager:** (e.g., npm, pnpm, yarn)
-- **Required env vars:** (list any needed for local dev)
-
-## Dev Server
-- **Start command:** (e.g., npm run dev)
-- **Default port:** (e.g., 3000)
-- **Health check:** (e.g., curl http://localhost:3000/health)
-
-## Notes
-(Any runtime-specific context the executor needs to know)

package/dist/resources/extensions/gsd/templates/secrets-manifest.md

@@ -1,22 +0,0 @@
-# Secrets Manifest
-
-<!-- This file lists predicted API keys and secrets for the milestone.
-     Each H3 section defines one secret with setup guidance.
-     The parser extracts entries by H3 heading (the env var name).
-     Bold fields: Service, Dashboard, Format hint, Status, Destination.
-     Guidance is a numbered list under each entry. -->
-
-**Milestone:** {{milestone}}
-**Generated:** {{generatedAt}}
-
-### {{ENV_VAR_NAME}}
-
-**Service:** {{serviceName}}
-**Dashboard:** {{dashboardUrl}}
-**Format hint:** {{formatHint}}
-**Status:** pending
-**Destination:** dotenv
-
-1. {{Step 1 guidance}}
-2. {{Step 2 guidance}}
-3. {{Step 3 guidance}}

package/dist/resources/extensions/gsd/templates/slice-context.md

@@ -1,58 +0,0 @@
----
-id: {{sliceId}}
-milestone: {{milestoneId}}
-status: {{draft|ready|in_progress|complete}}
----
-
-# {{sliceId}}: {{sliceTitle}} — Context
-
-<!-- Slice-scoped context. Milestone-only sections (acceptance criteria, completion class,
-     milestone sequence) do not belong here — those live in the milestone context. -->
-
-## Goal
-
-<!-- One sentence: what this slice delivers when it is done. -->
-
-{{sliceGoal}}
-
-## Why this Slice
-
-<!-- Why this slice is being done now. What does it unblock, and why does order matter? -->
-
-{{whyNowAndWhatItUnblocks}}
-
-## Scope
-
-<!-- What is and is not in scope for this slice. Be explicit about non-goals. -->
-
-### In Scope
-
-- {{inScopeItem}}
-
-### Out of Scope
-
-- {{outOfScopeItem}}
-
-## Constraints
-
-<!-- Known constraints: time-boxes, hard dependencies, prior decisions this slice must respect. -->
-
-- {{constraint}}
-
-## Integration Points
-
-<!-- Artifacts or subsystems this slice consumes and produces. -->
-
-### Consumes
-
-- `{{fileOrArtifact}}` — {{howItIsUsed}}
-
-### Produces
-
-- `{{fileOrArtifact}}` — {{whatItProvides}}
-
-## Open Questions
-
-<!-- Unresolved questions at planning time. Answer them before or during execution. -->
-
-- {{question}} — {{currentThinking}}

package/dist/resources/extensions/gsd/templates/slice-summary.md

@@ -1,108 +0,0 @@
----
-id: {{sliceId}}
-parent: {{milestoneId}}
-milestone: {{milestoneId}}
-provides:
-  - {{whatThisSliceProvides}}
-requires:
-  - slice: {{depSliceId}}
-    provides: {{whatWasConsumed}}
-affects:
-  - {{downstreamSliceId}}
-key_files:
-  - {{filePath}}
-key_decisions:
-  - {{decision}}
-patterns_established:
-  - {{pattern}}
-observability_surfaces:
-  - {{status endpoint, structured log, persisted failure state, diagnostic command, or none}}
-drill_down_paths:
-  - {{pathToTaskSummary}}
-duration: {{duration}}
-verification_result: passed
-completed_at: {{date}}
----
-
-# {{sliceId}}: {{sliceTitle}}
-
-<!-- One-liner must say what actually shipped, not just that work completed.
-     Good: "Structured job status endpoint with persisted failure diagnostics"
-     Bad: "Status feature implemented" -->
-
-**{{oneLiner}}**
-
-## What Happened
-
-{{narrative — compress task summaries into a coherent story}}
-
-## Verification
-
-{{whatWasVerifiedAcrossAllTasks — tests, builds, manual checks}}
-
-<!-- If the project has no REQUIREMENTS.md, omit all four requirement sections below entirely — do not fill them with "none". These sections only apply when requirements are being actively tracked. -->
-## Requirements Advanced
-
-- {{requirementId}} — {{howThisSliceAdvancedIt}}
-
-## Requirements Validated
-
-- {{requirementId}} — {{whatProofNowMakesItValidated}}
-
-## New Requirements Surfaced
-
-- {{newRequirementOr_none}}
-
-## Requirements Invalidated or Re-scoped
-
-- {{requirementIdOr_none}} — {{what changed}}
-
-## Operational Readiness
-
-<!-- Q8: How will ops know it's healthy/broken? OMIT ENTIRELY for simple slices with no runtime concerns. -->
-
-- **Health signal**: {{howToConfirmHealthy — health endpoint, heartbeat log, metric, or N/A}}
-- **Failure signal**: {{howToDetectBroken — error rate spike, alert, log pattern, or N/A}}
-- **Recovery**: {{selfRecoverOrRestart — auto-reconnect, circuit breaker, manual restart, or N/A}}
-- **Monitoring gaps**: {{silentFailureModes — background jobs, cache eviction, memory pressure, or none}}
-
-## Deviations
-
-<!-- Deviations are unplanned changes to the written plan, not ordinary debugging inside the plan's intended scope. -->
-
-{{deviationsFromPlan_OR_none}}
-
-## Known Limitations
-
-<!-- Known limitations are real gaps, rough edges, or deferred constraints that still exist after this slice shipped. -->
-
-{{whatDoesntWorkYet_OR_whatWasDeferredToLaterSlices}}
-
-## Follow-ups
-
-<!-- Follow-ups are concrete next actions discovered during execution, not a restatement of known limitations. -->
-
-{{workDeferredOrDiscoveredDuringExecution_OR_none}}
-
-## Files Created/Modified
-
-- `{{filePath}}` — {{description}}
-- `{{filePath}}` — {{description}}
-
-## Forward Intelligence
-
-<!-- Write what you wish you'd known at the start of this slice.
-     This section is read by the next slice's planning and research steps.
-     Be specific and concrete — this is the most valuable context you can transfer. -->
-
-### What the next slice should know
-- {{insightThatWouldHelpDownstreamWork}}
-
-### What's fragile
-- {{fragileAreaOrThinImplementation}} — {{whyItMatters}}
-
-### Authoritative diagnostics
-- {{whereAFutureAgentShouldLookFirst}} — {{whyThisSignalIsTrustworthy}}
-
-### What assumptions changed
-- {{originalAssumption}} — {{whatActuallyHappened}}

package/dist/resources/extensions/gsd/templates/state.md

@@ -1,17 +0,0 @@
-# GSD State
-
-**Active Milestone:** {{milestoneId}}: {{milestoneTitle}}
-**Active Slice:** {{sliceId}}: {{sliceTitle}}
-**Active Task:** {{taskId}}: {{taskTitle}}
-**Phase:** {{phase}}
-**Next Action:** {{nextAction}}
-**Last Updated:** {{date}}
-**Requirements Status:** {{activeCount}} active · {{validatedCount}} validated · {{deferredCount}} deferred · {{outOfScopeCount}} out of scope
-
-## Recent Decisions
-
-- {{decision}}
-
-## Blockers
-
-- (none)

package/dist/resources/extensions/gsd/templates/task-plan.md

@@ -1,87 +0,0 @@
----
-# Optional scope estimate — helps the plan quality validator detect over-scoped tasks.
-# Tasks with 10+ estimated steps or 12+ estimated files trigger a warning to consider splitting.
-estimated_steps: {{estimatedSteps}}
-estimated_files: {{estimatedFiles}}
-# Installed skills the planner expects the executor to load before coding.
-skills_used:
-  - {{skillName}}
----
-
-# {{taskId}}: {{taskTitle}}
-
-**Slice:** {{sliceId}} — {{sliceTitle}}
-**Milestone:** {{milestoneId}}
-
-## Description
-
-{{description}}
-
-## Failure Modes
-
-<!-- Q5: What breaks when dependencies fail? OMIT ENTIRELY for tasks with no external dependencies. -->
-
-| Dependency | On error | On timeout | On malformed response |
-|------------|----------|-----------|----------------------|
-| {{dependency}} | {{errorStrategy}} | {{timeoutStrategy}} | {{malformedStrategy}} |
-
-## Load Profile
-
-<!-- Q6: What breaks at 10x load? OMIT ENTIRELY for tasks with no shared resources or scaling concerns. -->
-
-- **Shared resources**: {{sharedResources — DB connections, caches, rate limiters, or none}}
-- **Per-operation cost**: {{perOpCost — N API calls, M DB queries, K bytes, or trivial}}
-- **10x breakpoint**: {{whatBreaksFirst — pool exhaustion, rate limit, memory, or N/A}}
-
-## Negative Tests
-
-<!-- Q7: What negative tests prove robustness? OMIT ENTIRELY for trivial tasks. -->
-
-- **Malformed inputs**: {{malformedInputTests — empty string, null, oversized, wrong type}}
-- **Error paths**: {{errorPathTests — network timeout, auth failure, 5xx, invalid JSON}}
-- **Boundary conditions**: {{boundaryTests — empty list, max length, zero, off-by-one}}
-
-## Steps
-
-1. {{step}}
-2. {{step}}
-3. {{step}}
-
-## Must-Haves
-
-- [ ] {{mustHave}}
-- [ ] {{mustHave}}
-
-## Verification
-
-- {{howToVerifyThisTaskIsActuallyDone}}
-- {{commandToRun_OR_behaviorToCheck}}
-
-## Observability Impact
-
-<!-- OMIT THIS SECTION ENTIRELY for simple tasks that don't touch runtime boundaries,
-     async flows, APIs, background processes, or error paths.
-     Include it only when the task meaningfully changes how failures are detected or diagnosed. -->
-
-- Signals added/changed: {{structured logs, statuses, errors, metrics}}
-- How a future agent inspects this: {{command, endpoint, file, UI state}}
-- Failure state exposed: {{what becomes visible on failure}}
-
-## Inputs
-
-<!-- Every input MUST be a backtick-wrapped file path. These paths are machine-parsed to
-     derive task dependencies — vague descriptions without paths break dependency detection.
-     For the first task in a slice with no prior task outputs, list the existing source files
-     this task reads or modifies. -->
-
-- `{{filePath}}` — {{whatThisTaskNeedsFromPriorWork}}
-
-## Expected Output
-
-<!-- Every output MUST be a backtick-wrapped file path — the specific files this task creates
-     or modifies. These paths are machine-parsed to derive task dependencies.
-     This task should produce a real increment toward making the slice goal/demo true. A full
-     slice plan should not be able to mark every task complete while the claimed slice behavior
-     still does not work at the stated proof level. -->
-
-- `{{filePath}}` — {{whatThisTaskCreatesOrModifies}}