dflow-sdd-ddd 0.14.0 → 0.16.0

package/templates/greenfield/templates/lightweight-spec.md

@@ -2,10 +2,13 @@
 id: BUG-{NUMBER}    # bug-type T2 only; a non-bug T2 (lightweight-{date}-{slug}.md) carries no id — the filename identifies it
 title: {簡述問題}
 status: in-progress    # in-progress | completed
-bounded-context: {ContextName}
+bounded-context: {ContextName}    # or `none` when the host has no meaningful bounded context
 created: {YYYY-MM-DD}
-branch: bugfix/BUG-{NUMBER}-{slug}
+branch: bugfix/BUG-{NUMBER}-{slug}    # must equal the host _index.md `branch:` value (that field is authoritative) — a non-bug T2 therefore carries the host's feature/{SPEC-ID}-{slug} branch
+# hotfix-branch: hotfix/{name}    # ADD (uncomment) only for a post-hoc T2 — references/modify-existing-flow.md Step 1.8. The already-merged emergency fix's own branch, kept even after that branch was deleted.
+# hotfix-identity: {PR / incident / tracker reference}    # ADD only for a post-hoc T2 — the source the asserted `reconciled ({merged-hotfix-hash})` identity rests on; an uncited hash blocks closeout. Keep it adjacent to hotfix-branch.
 ---
+<!-- dflow-shape: greenfield/lightweight-spec.md 1 — keep this line: dflow doctor reads it -->
 
 <!--
 Template note (for AI):
@@ -16,7 +19,7 @@ Template note (for AI):
   - T1 Heavy → use templates/phase-spec.md instead
   - T2 Light → THIS template; produces an independent file
   - T3 Trivial → no independent file; just one inline row in _index.md
-                 Lightweight Changes with a tag like [cosmetic] / [text] / [format]
+                 Lightweight Changes with a tag like [cosmetic] / [text] / [appearance]
 
   Instance file location and naming:
     Place the instantiated file inside the corresponding feature directory:
@@ -24,17 +27,136 @@ Template note (for AI):
     or, when the lightweight change is a tracked bug:
       dflow/specs/features/active/{SPEC-ID}-{slug}/BUG-{NUMBER}-{slug}.md
 
-    If the change is a standalone bug not yet attached to any existing
-    feature, /dflow:bug-fix must first create a feature directory (with a
-    minimal _index.md) before placing the lightweight-spec instance inside.
-    This keeps the structure invariant: every spec file lives under some
-    feature directory.
-
-  After finalizing this lightweight-spec, AI must:
+    A standalone change not yet attached to any existing feature needs a
+    minimal host feature directory (with a minimal _index.md) to hold this
+    instance — the structure invariant is that every spec file lives under
+    some feature directory. That minimal host has a defined create / record /
+    close-out lifecycle: references/modify-existing-flow.md Step 1.7 for a
+    standalone change, or its Step 1.6 minimal variant when the change is a
+    follow-up on a completed feature; a post-hoc hotfix reaches the same
+    lifecycle through Step 1.8, which resolves its linkage to one of those two.
+    Follow that lifecycle rather than
+    improvising one, and do not leave an empty host behind.
+
+  No-BR variants (a T2 that carries no BR delta at all):
+    The default shape below is the classic BR-delta form (Behavior Delta with
+    BR-NN entries + Root Cause). It stays valid and is the right shape whenever
+    the change does have a BR delta.
+    A change can reach T2 carrying no BR delta at all. These families describe
+    how to write a spec the cascade has ALREADY placed at T2; none of them
+    makes a change T2, and none of them overrides an earlier cascade step. Do
+    NOT invent a BR-NN and do NOT write a fake root cause. Pick the matching
+    family, put its BR line under `## Behavior Delta` in place of the
+    ADDED / MODIFIED / REMOVED / RENAMED subsections, and replace `## Root Cause`
+    with that family's evidence section:
+
+    (a) presentation — any copy / appearance change T3 would not take: a sweep
+        beyond the local unit, a whole-screen rewrite, a local edit to
+        high-consequence content (a security warning, a password hint,
+        consent text, a payment or legal notice), or one that changes what the output *means* (an
+        instruction reversed from "company email only" to "any email", a
+        danger / status colour flipped)
+        BR line: `BR: none — presentation`
+        Evidence: `## Output Footprint` — which screens / outputs the change
+        actually reaches, and **what it now says or signals** whenever the
+        meaning moved or the content is high-consequence
+    (b) contract change — non-breaking structured-log / export / API / event
+        field or semantics change
+        BR line: `BR: none — contract change`
+        Evidence: `## Contract Delta`, including a `**Downstream consumers**:`
+        line naming who reads it
+    (c) operational — CVE / security dependency bump, or a behavior-preserving
+        refactor on an auth / payment / resilience / compliance path
+        BR line: `BR: none — operational`
+        Evidence: `## Operational Rationale`, including a `**Trace**:` line
+        (advisory / ticket / audit reference; a self-initiated case with nothing
+        to cite records `**Trace**: none — self-initiated` — the line is never
+        omitted)
+    (d) performance — a runtime performance / resource / SLA change, including
+        one no audience perceives
+        BR line: `BR: none — performance`
+        Evidence: `## Performance Delta`, including an
+        `**SLA / resource context**:` line
+    (e) implementation defect — the rule is unchanged; the implementation was
+        wrong
+        BR lines: `BR Delta: none — implementation defect` AND
+        `Governing BR-IDs: {BR-NN, BR-NN | none}`
+        Evidence: keep `## Problem` / `## Root Cause` / `## Fix Approach`, plus a
+        regression task
+    (f) intentional change — a planned, non-normative functional or interaction
+        change with no rule in the catalogue (default tab, redirect target,
+        ordering, a presentation / interaction control)
+        BR line: `BR: none — intentional change`
+        Evidence: `## Change Rationale`, including `**Before**` / `**After**`
+        behavior lines and a `**Regression**:` line
+
+    More than one family can fit — a behaviour-preserving payment-retry refactor
+    that also shifts runtime SLA is both (c) and (d). Do not pick one and drop
+    the other's evidence: write the BR line of the family with the higher
+    consequence (order: (e) → (c) → (b) → (d) → (f) → (a)) and include **every**
+    matching family's evidence section. A reviewer needs the operational trace
+    and the SLA context, not whichever one the author chose first.
+
+    Family (e) keeps two fields on purpose: "no BR delta" is not "no governing
+    rule". `Governing BR-IDs:` lists the rules the defect sits under, so the rule
+    the fix answers to stays traceable; a genuinely uncatalogued defect records
+    `none`. Never collapse the pair into a single `BR: none`.
+    Family (f) is non-normative only. A new normative constraint (permission /
+    eligibility / threshold / approval / required outcome) is a new BR — take it
+    back to the cascade rather than filing it here, even when the catalogue has
+    no BR-ID for it yet.
+
+    Legacy shapes are accepted, never migrated. Readers and gates take both the
+    classic BR-delta form and the older single `BR:` line bug form (written
+    before the `BR Delta:` / `Governing BR-IDs:` split) as they are; leave
+    existing specs alone and use the shapes above for new ones.
+
+  After drafting this lightweight-spec, AI must:
     1. Add an outbound-link row to the feature's _index.md Lightweight Changes table
-       (Tier = T2; description includes the link to this file)
+       (Tier = T2; description includes the link to this file).
+       TIMING — do this BEFORE the implementation commit, not after. On a
+       minimal (zero-phase) host the row must already be inside checkpoint 1,
+       and closeout's allow-list admits only the row's `Commit` cell
+       afterwards, so a row added later blocks. "Drafting", not the Step 1.7
+       "Finalize + close" sub-step, which runs after that commit and only fills
+       the cell in.
     2. Refresh the feature's _index.md Current BR Snapshot table to reflect
        any BR ADDED / MODIFIED / REMOVED / RENAMED in this lightweight-spec
+       (a no-BR family has nothing to refresh — leave the snapshot as it is)
+
+  Implementation Paths:
+    The `## Implementation Paths` section below names the source paths this
+    change touches. Paths, not a diff — enough to compare a commit against.
+    REQUIRED on a minimal (zero-phase) host — standalone or follow-up:
+    `/dflow:finish-feature` asserts that checkpoint 1's diff touches them, so a
+    spec declaring none leaves that check nothing to compare and a missing
+    declaration BLOCKS closeout rather than passing vacuously
+    (references/finish-feature-flow.md Step 1; written at
+    references/modify-existing-flow.md Step 1.7, before the first commit).
+    On a HOSTED T2 — one recorded under a phase-bearing feature — closeout runs
+    no such check and nothing blocks on it, so the section is good practice
+    there, not a gate. Do not read the "blocks" above as applying to a hosted
+    spec; it does not.
+    Keep the paths OUT of `## Implementation Tasks`: the completion checklist
+    may collapse or remove that section once the tasks are done, and the paths
+    must still be readable at closeout.
+
+  Post-hoc hotfix fields — T2 only, references/modify-existing-flow.md Step 1.8:
+    `hotfix-branch:` records the already-merged emergency fix's own branch
+    (keep the value even when that branch has been deleted); `hotfix-identity:`
+    cites what the identity claim rests on — the PR, incident, or tracker
+    reference. Both live in the frontmatter, adjacent, so the trace and the
+    thing it rests on stay together. They ship COMMENTED OUT: an ordinary
+    (non-post-hoc) T2 leaves them commented and they are inert. Uncomment them
+    only in post-hoc mode — never fill them with `none`, and never leave them
+    live on an ordinary T2, which would claim a hotfix branch that never
+    existed on a record nothing else re-checks.
+    In post-hoc mode `## Implementation Paths` names the paths the MERGED
+    HOTFIX touched: closeout compares them against the `reconciled ({hash})`
+    commit, and blocks if this host's own documentation commit touches any of
+    them (that would be re-implementation, not reconciliation). Closeout tests
+    plausibility only and blocks on an uncited hash; the identity itself is
+    confirmed by references/pr-review-checklist.md.
 -->
 
 # {問題簡述}
@@ -46,6 +168,8 @@ Template note (for AI):
 ## Behavior Delta
 
 > 精簡 delta 格式：bug fix 多數只需 MODIFIED；若確實是新增規則可改用 ADDED、移除用 REMOVED、改名用 RENAMED。多項變更時照類別列。
+>
+> 完全沒有 BR delta 時改用 no-BR 家族形（見檔首 Template note 的 No-BR variants）：本段只留該家族的 BR 行（例如 `BR: none — presentation`；家族 (e) 是 `BR Delta:` + `Governing BR-IDs:` 兩行），不要為了填滿 delta 子段捏造 BR-NN。
 
 ### MODIFIED - behavior modified in this fix
 #### Rule: BR-NN {規則名稱}
@@ -58,12 +182,31 @@ Template note (for AI):
 
 ## Root Cause
 
+> classic BR-delta 形與 no-BR 家族 (e) 保留本段；家族 (a)–(d)、(f) 以該家族的 evidence 段取代本段（見檔首 Template note 的 No-BR variants）。
+
 {為什麼會這樣？是邏輯錯誤？資料問題？還是需求理解有誤？}
 
 ## Fix Approach
 
 {怎麼修？有沒有抽到 Domain 層的機會？}
 
+## Implementation Paths
+
+> The source paths this change touches — paths, not a diff, at a granularity a
+> commit can be compared against. **Required on a minimal (zero-phase) host**:
+> `/dflow:finish-feature` asserts checkpoint 1's diff touches them, and
+> declaring none **blocks** closeout instead of passing. On a **hosted** T2 —
+> recorded under a phase-bearing feature — closeout runs no such check, so this
+> is good practice there rather than a gate. Do not move the list into
+> `## Implementation Tasks`: that section may be collapsed once the tasks are
+> done, and these paths must still be readable at closeout.
+>
+> **Post-hoc hotfix (Step 1.8)**: list what the **already-merged hotfix**
+> touched. This host's own documentation commit must **not** touch any of them.
+
+- `{src/path/touched}`
+- `{src/another/path/touched}`
+
 <!-- dflow:section implementation-tasks -->
 ## Implementation Tasks
 

package/templates/greenfield/templates/models.md

@@ -1,3 +1,4 @@
+<!-- dflow-shape: greenfield/models.md 1 — keep this line: dflow doctor reads it -->
 <!-- Seeded by Dflow. -->
 <!-- Formatting convention: keep table cells concise. When one cell holds multiple short items (invariants, rules, steps), separate them with <br> so each renders on its own line - never chain them into one line with ；/; separators. Long narrative detail does not belong in a table cell: keep the cell to a concise summary and put extended detail in an existing section of this document when one fits, or give each item its own row. -->
 

package/templates/greenfield/templates/phase-spec.md

@@ -7,6 +7,7 @@ created: {YYYY-MM-DD}
 author: {developer-name}
 branch: feature/{SPEC-ID}-{slug}
 ---
+<!-- dflow-shape: greenfield/phase-spec.md 1 — keep this line: dflow doctor reads it -->
 
 <!-- Formatting convention: keep table cells concise. When one cell holds multiple short items (invariants, rules, steps), separate them with <br> so each renders on its own line - never chain them into one line with ；/; separators. Long narrative detail does not belong in a table cell: keep the cell to a concise summary and put extended detail in an existing section of this document when one fits, or give each item its own row. -->
 
@@ -17,7 +18,14 @@ Template note (for AI):
   This is the **phase-spec** template - one phase-spec captures one full
   "Kickoff -> Domain -> Design -> Build -> Verify" cycle inside a feature directory.
   A feature can have 1..N phase-specs; the feature-level dashboard lives in
-  the sibling `_index.md` (see templates/_index.md). The instance file name is
+  the sibling `_index.md` (see templates/_index.md).
+  Exception — a **minimal (zero-phase) host** has **0**: it records a small
+  standalone or follow-up change and is defined by carrying no phase-spec at
+  all (references/modify-existing-flow.md Step 1.7, or its Step 1.6 minimal
+  variant). Such a host never uses this template. If you are about to create a
+  phase-spec for one, stop: adding a phase makes it a phase-bearing feature,
+  and closeout will then check it as one.
+  The instance file name is
   `phase-spec-YYYY-MM-DD-{slug}.md` placed at
   `dflow/specs/features/active/{SPEC-ID}-{slug}/`.
 

package/templates/greenfield/templates/rules.md

@@ -1,3 +1,4 @@
+<!-- dflow-shape: greenfield/rules.md 1 — keep this line: dflow doctor reads it -->
 <!-- Seeded by Dflow. -->
 <!-- Formatting convention: keep table cells concise. When one cell holds multiple short items (invariants, rules, steps), separate them with <br> so each renders on its own line - never chain them into one line with ；/; separators. Long narrative detail does not belong in a table cell: keep the cell to a concise summary and put extended detail in an existing section of this document when one fits, or give each item its own row. -->
 

package/templates/greenfield/templates/tech-debt.md

@@ -1,3 +1,4 @@
+<!-- dflow-shape: greenfield/tech-debt.md 1 — keep this line: dflow doctor reads it -->
 <!-- Seeded by Dflow. -->
 <!-- Formatting convention: keep table cells concise. When one cell holds multiple short items (invariants, rules, steps), separate them with <br> so each renders on its own line - never chain them into one line with ；/; separators. Long narrative detail does not belong in a table cell: keep the cell to a concise summary and put extended detail in an existing section of this document when one fits, or give each item its own row. -->
 

package/templates/brownfield/references/dflow-feedback-flow.md

@@ -1,251 +0,0 @@
-# Dflow Feedback Draft Flow
-
-`/dflow:report-dflow-feedback` helps the developer turn a Dflow problem or
-improvement observed during real project work into a high-quality upstream
-feedback draft. The draft is rendered **field by field to match the upstream
-GitHub issue form**, so the developer pastes each field with no reformatting.
-
-This flow is **not** a project feature workflow and does not change the
-application being built. It is a standalone governance/support flow for Dflow
-itself.
-
-## Hard Boundaries
-
-- Do not submit anything to GitHub automatically.
-- Do not run `gh issue create`, `gh pr create`, `git push`, or any networked
-  submission command from this flow.
-- Do not expose private project details, business rules, customer data,
-  secrets, tokens, internal URLs, or proprietary source snippets.
-- Always show the draft to the developer before anything leaves the local
-  machine.
-- If the developer later asks to submit through GitHub CLI, stop and treat that
-  as a separate explicit task with fresh permission and environment checks.
-
-## Trigger Conditions
-
-Enter this flow when:
-
-- The developer explicitly runs `/dflow:report-dflow-feedback`.
-- The developer says the Dflow process, template, generated file, or docs seem
-  wrong or improvable.
-- The AI notices a clear contradiction or gap in Dflow guidance and asks:
-  "This looks like a possible Dflow upstream issue. Should I draft feedback for
-  you to review?"
-
-Do not interrupt normal development for minor preference differences. If the
-observation is speculative, ask before drafting.
-
-## Output Location
-
-Write the draft to:
-
-```text
-dflow/feedback/dflow-feedback-YYYY-MM-DD-{slug}.md
-```
-
-Create `dflow/feedback/` if it does not exist. The file is local project
-working material; the developer decides whether to copy it into a GitHub issue,
-turn it into a PR, or discard it.
-
-## Step 1: Classify the Feedback
-
-Classify the feedback as one of the following. Each maps to one upstream issue
-form (see "Upstream Issue Forms" below):
-
-| Classification | Upstream issue form | Title prefix |
-|---|---|---|
-| Bug report | Bug report | `[Bug]: ` |
-| Workflow change request | Workflow change request | `[Workflow]: ` |
-| Documentation feedback | Documentation feedback | `[Docs]: ` |
-| Question / unclear usage | Question | `[Question]: ` |
-| Maintainer release/process feedback | Workflow change request (closest form; the upstream repo disables blank issues) | `[Workflow]: ` |
-
-Capture:
-
-- Observed during which flow or command
-- Affected Dflow track: Greenfield, Brownfield, both, or unknown
-- Affected area: CLI, generated template, scaffolding, skill reference,
-  tutorial, README/docs, release/governance
-- Whether the issue blocks current project work
-
-## Step 2: Capture Evidence Safely
-
-Collect only the evidence needed to explain the Dflow issue.
-
-Allowed evidence:
-
-- Dflow command name
-- Dflow version if known
-- Template or reference file name
-- Generic project type, such as "existing brownfield app" or "legacy batch-processing system"
-- Minimal paraphrased symptom
-- Short sanitized snippets from Dflow-owned files
-
-Avoid:
-
-- Internal business rules
-- Customer or tenant names
-- Private repository names or URLs
-- Secrets, tokens, credentials, or auth headers
-- Long proprietary code snippets
-- Full logs containing private paths or environment data
-
-## Step 3: Redaction Pass
-
-Before writing any field content, run a redaction check and use it as your own
-gate. Confirm there are:
-
-- No secrets, tokens, credentials, or auth headers
-- No customer, tenant, or private organization names
-- No proprietary business rules beyond a sanitized paraphrase
-- No private repository URLs or internal hostnames
-- No long proprietary source snippets
-
-The draft ends with a short submitter self-check (Step 5); leave its items
-unchecked unless the developer explicitly confirms them.
-
-## Step 4: Resolve the Target Issue Form
-
-Submit upstream at: **https://github.com/weilung/dflow-sdd-ddd/issues/new/choose**
-
-Resolve the field schema for the chosen form using this priority chain (it
-avoids any network dependency at draft time):
-
-1. **Live upstream schema** — if you can read the target repo's
-   `.github/ISSUE_TEMPLATE/*.yml` (for example you are working inside a
-   `dflow-sdd-ddd` checkout), use that file; it is authoritative.
-2. **Bundled field map** — otherwise use the field map in "Upstream Issue
-   Forms" below. It is a snapshot of the upstream forms shipped with Dflow.
-3. **Generic fallback** — only if the feedback matches none of the forms, use
-   Step 6.
-
-## Step 5: Render the Draft Field by Field
-
-Write the draft as one block per upstream field, in the form's field order, so
-the developer copies each block straight into the matching field.
-
-Per field-type rules:
-
-| Field type | How to render |
-|---|---|
-| `input` | One short line inside a fenced block. |
-| `textarea` | Multi-line content inside a fenced block. If the field sets a non-empty `render:` attribute, do **not** add an extra fence (the form already code-blocks it). |
-| `dropdown` | State the **recommended option** plus a one-line reason. If `multiple: true`, list the chosen options. |
-| `checkboxes` | List every option as `- [x]` / `- [ ]`; mark any option whose schema sets `required: true`. |
-| `markdown` | Display-only text in the form — produce **no** field block for it. |
-| upload / attachment | Emit a manual step ("drag the relevant screenshot / log into the issue editor"); do not try to handle the file. |
-
-Always start with a **Title** block: the form's title prefix plus a concise
-one-line summary. GitHub pre-fills the prefix in the title box; the developer
-can paste the full line over it.
-
-Attribute handling: bring `value` / `default` in as starting content; surface
-`placeholder` as a hint; append "(required)" to the block heading when the
-field sets `required: true`.
-
-**Fence escaping (dynamic).** Wrap each field's content in a backtick fence
-whose length is *(longest backtick run in the content) + 1*, minimum 3. The
-fence is only a local wrapper so the content survives in the draft file — when
-pasting into the issue form, the developer copies the **inner** content, not
-the fence. State this in the draft.
-
-Draft skeleton:
-
-````markdown
-# {Issue form name} — {short title}
-
-## Where to submit
-
-https://github.com/weilung/dflow-sdd-ddd/issues/new/choose → choose
-**"{Issue form name}"**. (A GitHub account is all you need; the title is
-auto-prefixed with `{prefix}`.)
-
-## Title
-
-```
-{prefix}{concise one-line summary}
-```
-
-## {Field label} (required)
-
-```
-{field content; copy the inner text only, not this fence}
-```
-
-... one block per field, in form order ...
-
-## Before you submit (submitter self-check)
-
-- [ ] Any real file names / customer names / internal project code names to redact?
-- [ ] If you attach screenshots, do they show sensitive content (internal systems, tokens, passwords)?
-- [ ] Is opening a public issue within what your organization allows?
-````
-
-Keep the draft **submitter-facing only**: no maintainer tracking notes, no
-internal references, no "for your friend / for yourself" audience switches.
-
-## Upstream Issue Forms (bundled field map)
-
-> Snapshot of the `weilung/dflow-sdd-ddd` issue forms. If the live `.yml` is
-> reachable (Step 4 priority 1), prefer it. Resync this map when the upstream
-> forms change.
-
-### Bug report — title `[Bug]: `
-
-| Field | Type | Required | Notes |
-|---|---|---|---|
-| Dflow version | input | yes | placeholder `0.2.0` |
-| Node.js version | input | yes | from `node --version` |
-| Project track | dropdown | yes | Greenfield / Brownfield / Not sure |
-| Command or workflow | textarea | yes | the command or `/dflow:*` workflow used |
-| Expected behavior | textarea | yes | |
-| Actual behavior | textarea | yes | include relevant output |
-| Reproduction steps | textarea | yes | smallest steps that reproduce |
-| Additional context | textarea | no | screenshots / snippets / environment |
-
-### Workflow change request — title `[Workflow]: `
-
-| Field | Type | Required | Notes |
-|---|---|---|---|
-| Problem | textarea | yes | |
-| Proposed change | textarea | yes | |
-| Affected track | dropdown | yes | Greenfield / Brownfield / Both / Not sure |
-| Affected area | checkboxes | no | CLI command / Generated template / Generated scaffolding / Skill workflow guidance / Tutorial or examples / Documentation only |
-| Compatibility risk | textarea | yes | |
-| Alternatives considered | textarea | no | |
-
-### Documentation feedback — title `[Docs]: `
-
-| Field | Type | Required | Notes |
-|---|---|---|---|
-| Affected page or file | input | yes | placeholder `README.md` |
-| Reader goal | textarea | yes | what you were trying to understand or do |
-| What was confusing? | textarea | yes | the missing, unclear, or misleading part |
-| Suggested improvement | textarea | no | optional wording or structure |
-
-### Question — title `[Question]: `
-
-| Field | Type | Required | Notes |
-|---|---|---|---|
-| Project type | dropdown | yes | New project / Existing project / Not sure |
-| Dflow track you are considering | dropdown | yes | Greenfield / Brownfield / Not sure |
-| What are you trying to do? | textarea | yes | the workflow or decision you need help with |
-| Project context | textarea | no | framework, team workflow, AI agent, constraints |
-
-## Step 6: Generic Fallback
-
-Use this only when the feedback matches none of the forms above. The upstream
-repo disables blank issues, so direct the developer to pick the closest form at
-`https://github.com/weilung/dflow-sdd-ddd/issues/new/choose` and adapt. Emit
-two paste-ready blocks — a `Title` and a `Body` — plus the URL. Do **not** fall
-back to a generic `## Problem` / `## Evidence` Markdown draft.
-
-## Step 7: Present Submission Options
-
-After writing the draft, name the draft file path and whether any submitter
-self-check items remain unchecked, then summarize the options:
-
-- Open the chosen issue form and paste each field block.
-- Discard the draft if it was only a local observation.
-
-Do not submit anything automatically.