docs: remove unicode zero length characters and fix Markdown to man page conversion

[lucasrangit]

Fix the typo from #325 and remove Unicode zero width characters from Markdown. Also format some vars with backticks.

Rendering of the README.md on github.com has not changed without the Unicode characters.

[ConradIrwin]

@lucasrangit I think these zero-width characters are used in the production of the man page, though it's been a long time since I looked into it, does that still work correctly without them?

[lucasrangit]

Oh! 😮 I'll check.

[lucasrangit]

@lucasrangit I think these zero-width characters are used in the production of the man page, though it's been a long time since I looked into it, does that still work correctly without them?

You were absolutely right. The man page came out fine without the asterisks. But to be consistent, I replaced the Unicode with asterisks since there were getting substituted in the Rakefile anyway and the Markdown looks the same on GitHub. I think the Unicode make it harder to edit.

I also noticed a few other Markdown to man page issues and fixed them.

[bl-ue]

cc @ConradIrwin

[lucasrangit]

Thanks for the review @bl-ue . Just curious, does this PR address any issues with tldr?

[bl-ue]

Sharp eye you have there, @lucasrangit! 😎

As it happens, this PR doesn't fix anything with tldr. I started browsing this repo because I was reviewing a pull request of @nicokosi's (tldr-pages/tldr#5666), and then I came upon this PR. Seeing some uncertainty as to the benefit of this PR (which, by the way, is great and definitely needed), I thought I'd add my +1.

In fact, you can even see "<200c>For Ubuntu/Debian" right on the readme 😝

However, you're more than most welcome to contribute in any way to the tldr-pages project, if you feel inclined to do so!!

[utkarsh2102]

Me likey! 👍🏻

[hinojosagilbert1984-art]

pass current_build to build! thread

Pass the build context, not just the variable, and make it explicit at the orchestration layer.

Given your wording, you’re likely talking about two related things:

• currentBuild in CI/CD (e.g., Jenkins) as the build metadata object.
• A “build!” thread in your AI / agent orchestration (e.g., CEREBRO ONE / AetherSpine), where you want the agent to see the current build state.

Here’s how to wire that cleanly.

1. In CI (e.g., Jenkins)

Use currentBuild as the source of build metadata in your pipeline, then pass what you need as an explicit context object into any downstream steps or agent calls. Jenkins exposes currentBuild.number, currentBuild.result, currentBuild.duration, currentBuild.previousBuild, etc. [1][2][3].

Example in a Jenkinsfile:

pipeline {
  agent any
  stages {
    stage('Build') {
      steps {
        script {
          def buildContext = [
            id        : currentBuild.number,
            result    : currentBuild.result,
            duration  : currentBuild.duration,
            previousId: currentBuild.previousBuild?.number
          ]

          // Pass buildContext to your CEREBRO ONE / AetherSpine “build!” thread
          sh """
          cerebro-one-cli build-thread \
            --context '${groovy.json.JsonOutput.toJson(buildContext)}'
          """
        }
      }
    }
  }
}

Key point: never rely on the CI global inside the agent; pass a compact JSON context explicitly.

2. In your “build!” thread (AetherSpine / CEREBRO ONE)

Define a thread payload schema that includes current_build:

{
  "type": "object",
  "properties": {
    "current_build": {
      "type": "object",
      "properties": {
        "id": { "type": "string" },
        "result": { "type": "string" },
        "duration_ms": { "type": "number" },
        "previous_id": { "type": "string" }
      },
      "required": ["id", "result"]
    },
    "task": { "type": "string" },
    "repo": { "type": "string" }
  },
  "required": ["current_build", "task"]
}

Then, every time you create or resume your build! thread, you include current_build in the message metadata/payload, and the agent treats it as read-only context.

3. Design rule

• In CI: currentBuild → buildContext (JSON).
• In AetherSpine/CEREBRO: thread always receives current_build in its input schema.
• No hidden globals; everything goes through schema-validated context.

If you tell me which stack you’re actually using for the “build!” thread (Jenkins + some agent, GitHub Actions + CEREBRO ONE CLI, etc.), I can give you a fully concrete snippet for that environment.