The README and the project documents are in ASD-STE100

The README, CONTRIBUTING, SECURITY, the docs index, the development
documents, the script READMEs, the comments of config.example.toml and
pyproject.toml, and the issue and pull request forms. The legal sections
of the README (attribution and licence) stay exactly as they were, between
ste: off and ste: on markers. The SignPath attribution line, the one-line
description of MeshTerm, every code block, and every URL do not change.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

.github/ISSUE_TEMPLATE/bug.yml

@@ -5,30 +5,30 @@ body:
   - type: markdown
     attributes:
       value: |
-        Hopefully you never need this form.
+        We hope that you never need this form.
 
-        If you do: start by running this, and attach the file it writes.
+        If you do need it, first run this command and attach the file that it writes.
 
         ```
         meshterm diagnostics --out bug.md
         ```
 
-        It answers which MeshTerm, on which machine, in which terminal, talking to which
-        radio over which transport and firmware — most of what I would otherwise ask one
-        question at a time, and the details people most often end up guessing at. Nothing
-        in it is private: no keys, no pairing PINs, no positions, no contacts. That is a
-        tested property, not a promise.
+        The file says which MeshTerm you use, on which machine, in which terminal, and with
+        which radio, transport, and firmware. This is most of the information that I would
+        otherwise ask for in single questions. It is also the information that people most
+        often guess. The file has no private information: no keys, no pairing PINs, no
+        positions, and no contacts. A test checks this. It is not only a promise.
 
-        The **Diagnostics** page in the menu saves the same file (with `s`, or F3 on the
-        PicoCalc), next to the log.
+        The **Diagnostics** page in the menu saves the same file next to the log. Press `s`,
+        or F3 on the PicoCalc.
 
-        The rest of this form asks only for what that file cannot know.
+        The rest of this form asks only for the information that the file cannot know.
 
   - type: textarea
     id: problem
     attributes:
-      label: What's the problem
-      description: What happens, and what you expected to happen instead.
+      label: What is the problem
+      description: What happens, and what you expected to happen.
     validations:
       required: true
 
@@ -47,11 +47,12 @@ body:
   - type: textarea
     id: repro
     attributes:
-      label: How do I make it happen
+      label: How can I make it happen
       description: >
-        The steps, in order, starting from launching MeshTerm. Screens and keys beat
-        descriptions — "Contacts, Enter on a node, Routes tab, Enter on the second route"
-        is worth more than "open a trace".
+        Write the steps in order. Start from the time that you start MeshTerm. Name the
+        screens and the keys. This is more useful than a description. For example,
+        "Contacts, Enter on a node, Routes tab, Enter on the second route" is better than
+        "open a trace".
       placeholder: |
         1.
         2.
@@ -64,15 +65,16 @@ body:
     attributes:
       label: Does it still happen with `meshterm --mock`
       description: >
-        `--mock` runs the whole app against a fake radio. If the bug survives that, it is
-        in MeshTerm and I can chase it without owning your hardware. If it doesn't, it is
-        in the link or the radio, which is a different hunt. This one question decides
-        which of those two jobs this is, so it is worth the minute it takes.
+        `--mock` runs the complete app with a fake radio. If the bug also occurs with
+        `--mock`, the bug is in MeshTerm, and I can look for it without your hardware. If
+        the bug does not occur with `--mock`, it is in the link or in the radio. This is a
+        different search. This one question tells me which of the two jobs this is, so
+        please take the minute to answer it.
       options:
         - "Yes, still happens with --mock"
         - "No, --mock is fine"
-        - "Haven't tried"
-        - "Doesn't apply — the problem is connecting"
+        - "I have not tried it"
+        - "Does not apply: the problem is the connection"
     validations:
       required: true
 
@@ -81,9 +83,9 @@ body:
     attributes:
       label: The diagnostics block
       description: >
-        Attach `bug.md` by dragging it in, or paste its contents here. If you genuinely
-        cannot produce one, because MeshTerm will not start at all, write down why instead,
-        along with your version, and I will work with that.
+        Drag `bug.md` into this field, or paste its contents here. If you cannot make the
+        file, because MeshTerm does not start at all, write the reason instead. Also write
+        your version. I will work with that information.
     validations:
       required: true
 
@@ -92,9 +94,9 @@ body:
     attributes:
       label: Which handheld, if it is a handheld
       description: >
-        Only if you are running on something the diagnostics file cannot name. It knows a
-        PicoCalc from a regular terminal, but a uConsole and a laptop look much the same to
-        it. Leave blank on a desktop, laptop, or Mac.
+        Answer this only if you use a device that the diagnostics file cannot name. The file
+        can tell a PicoCalc from a regular terminal. But a uConsole and a laptop look almost
+        the same to it. Leave this blank on a desktop, a laptop, or a Mac.
       placeholder: "ClockworkPi uConsole (CM4)"
 
   - type: input
@@ -102,10 +104,10 @@ body:
     attributes:
       label: Which radio and firmware, if MeshTerm could not reach it
       description: >
-        The diagnostics file reads the model and firmware off the radio itself, so when the
-        problem *is* connecting, it has nothing to read. That is the one case where I need
-        you to tell me. Be precise — "a Xiao" covers several boards that do not behave
-        alike.
+        The diagnostics file reads the model and the firmware from the radio itself. When
+        the problem is the connection, the file has nothing to read. In this one case, I
+        need you to tell me. Be exact. "A Xiao" can mean several boards that do not behave
+        in the same way.
       placeholder: "Seeed XIAO nRF52840 + Wio-SX1262, MeshCore 1.15.0"
 
   - type: textarea
@@ -113,8 +115,9 @@ body:
     attributes:
       label: The exact error, if there was one
       description: >
-        Copy it as text rather than photographing the screen — text can be searched, and a
-        photo of a terminal is hard to read. Paste the whole traceback if it crashed.
+        Copy it as text. Do not take a photograph of the screen. A search can find text, and
+        a photograph of a terminal is difficult to read. If MeshTerm crashed, paste the
+        complete traceback.
       render: text
 
   - type: textarea
@@ -122,22 +125,22 @@ body:
     attributes:
       label: The log file
       description: >
-        MeshTerm keeps one at `~/.meshterm/meshterm.log` (or wherever `MESHTERM_HOME`
-        points). Attach the file, or paste the last twenty lines inside a ``` fence. If the
-        problem is hard to catch, set **Log detail** to Debug on the Preferences page,
-        restart MeshTerm, do it once more, and send that instead. It records a great deal
-        more.
+        MeshTerm keeps a log at `~/.meshterm/meshterm.log` (or at the place that
+        `MESHTERM_HOME` points to). Attach the file, or paste the last twenty lines inside a
+        ``` fence. If the problem is difficult to catch, set **Log detail** to Debug on the
+        Preferences page and restart MeshTerm. Then do the action one more time, and send
+        that log instead. It records much more information.
 
   - type: textarea
     id: workaround
     attributes:
       label: Is there a way around it
-      description: Anything that avoids it, or gets you unstuck. Say so even if it's ugly.
+      description: Write anything that avoids the problem or lets you continue. Tell us also when the way around is not good.
 
   - type: textarea
     id: extra
     attributes:
       label: Anything else
       description: >
-        Did it used to work? Did it start after an update? Screenshots of a wrong-looking
-        screen are genuinely useful here, even though text is better for errors.
+        Did it work before? Did the problem start after an update? Screenshots of a screen
+        that looks wrong are very useful here. For errors, text is better.

.github/ISSUE_TEMPLATE/config.yml

@@ -1,15 +1,16 @@
 blank_issues_enabled: false
 contact_links:
-  - name: Not sure it's a bug? Ask on Discord
+  - name: Not sure it is a bug? Ask on Discord
     url: https://discord.gg/AZwe5Uvb3S
     about: >
-      Setup trouble, "is it supposed to do this", or anything you want a second opinion
-      on. The #support forum is the place. Someone running your radio has probably hit it.
+      Use Discord for a problem with the setup, for the question "is it correct that it does
+      this", or when you want a second opinion. The #support forum is the correct place.
+      Probably someone who runs your radio had the same problem.
 
   - name: "No GitHub account? Report it in the #bugs forum instead"
     url: https://discord.gg/AZwe5Uvb3S
     about: >
-      One post per bug, tagged, with the diagnostics file attached. Real ones get opened
-      here and your post is renamed with the issue number, so you can follow it without an
-      account — and something comes back to tell you when it ships. Being told beats
-      filing it tidily.
+      Make one post for each bug. Add a tag, and attach the diagnostics file. I open an issue
+      here for each real bug, and I rename your post with the number of the issue. Thus you can
+      follow it without an account. You also get a message when the correction is released.
+      It is better that you tell us about a bug than that you file it in a tidy way.

.github/ISSUE_TEMPLATE/feature.yml

@@ -5,15 +5,15 @@ body:
   - type: markdown
     attributes:
       value: |
-        MeshTerm is one person's spare time, so the honest answer to a good idea is often
-        "yes, eventually". Saying what you are actually trying to do — rather than the
-        feature you have in mind — often finds something that already works.
+        One person works on MeshTerm in his spare time. For this reason, the honest answer to a
+        good idea is often "yes, but not soon". Tell us what you want to do, and not the
+        feature that you have in mind. Then we can often find a function that already works.
 
   - type: textarea
     id: problem
     attributes:
-      label: What are you trying to do
-      description: The situation you are in, not the feature. What are you trying to find out about your mesh?
+      label: What do you want to do
+      description: Describe your situation, and not the feature. What do you want to find out about your mesh?
     validations:
       required: true
 
@@ -21,10 +21,10 @@ body:
     id: idea
     attributes:
       label: What you had in mind
-      description: If you have a shape in mind — a screen, a key, a subcommand — describe it.
+      description: If you have an idea of the form, such as a screen, a key, or a subcommand, describe it.
 
   - type: textarea
     id: today
     attributes:
       label: What you do today instead
-      description: The workaround, if there is one. This says more about how much the feature is worth than anything else.
+      description: Describe the way around the problem, if there is one. This tells us more than anything else about how much the feature is worth.

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,30 +1,31 @@
 ## What this changes, and why
 
-<!-- The why matters more than the what — the diff already says the what. -->
+<!-- The reason is more important than the description of the change, because the diff already shows the change. -->
 
 ## Discord
 
-<!-- Your Discord username on the MeshTerm server, and a link to the message in
-     #contributing where you got a yes. A pull request without them is closed without
-     a review. -->
+<!-- Write your Discord username on the MeshTerm server. Also write a link to the message
+     in #contributing where you got a yes. We close a pull request without these items
+     and do not review it. -->
 
 Username:
 Link to the yes:
 
 ## AI use
 
-<!-- Required. Did an AI tool write any part of this change? If yes: which tool, what it
-     did, and what you checked yourself. Each commit it helped with also needs a line at
-     the end naming it, like `Co-Authored-By:` or `Assisted-by:`. If you used AI and don't
-     say so, this pull request is treated as a bot's and closed. -->
+<!-- This is necessary. Did an AI tool write any part of this change? If yes, write which
+     tool, what it did, and what you checked yourself. Each commit that it helped with also
+     needs a line at the end that names the tool, for example `Co-Authored-By:` or
+     `Assisted-by:`. If you used AI and you do not say so, we treat this pull request as a
+     bot's pull request and close it. -->
 
 ## Before you mark it ready
 
-- [ ] I've read [CONTRIBUTING.md](../blob/main/CONTRIBUTING.md) and agree its licensing terms apply to this contribution
-- [ ] I've put my Discord username and a link to the yes above
-- [ ] If I used AI, I said so above and in the commits it helped with
+- [ ] I have read [CONTRIBUTING.md](../blob/main/CONTRIBUTING.md) and I agree that its licensing terms apply to this contribution
+- [ ] I have written my Discord username and a link to the yes above
+- [ ] If I used AI, I said so above and in the commits that it helped with
 - [ ] `python -m pytest -q` passes, including the dual-platform gallery gate
-- [ ] `ruff check .` and `ruff format --check .` are clean
-- [ ] New screens, rows, and hints go through the helpers in `ui/menus.py`, and follow the
+- [ ] `ruff check .` and `ruff format --check .` have no errors
+- [ ] New screens, rows, and hints use the helpers in `ui/menus.py`, and follow the
       lexicon and UX standards in `CLAUDE.md`
-- [ ] Anything user-visible has a line in `CHANGELOG.md` under `[Unreleased]`
+- [ ] Anything that the user can see has a line in `CHANGELOG.md` under `[Unreleased]`