DotShare AI 3.5.2: From Git Tags to Technical Articles You Can Review

A deep dive into DotShare 3.5.2: release-aware AI articles, verified code excerpts, Dev.to live preview, and safer credential handling.

An AI release article can sound convincing while describing code that never shipped.

The failure is often subtle: a changelog comes from one version, source code comes from today's checkout, and an example gets rewritten into something that looks cleaner but no longer matches the implementation. By the time the article reaches the publishing screen, the facts have already drifted.

DotShare AI 3.5.2 makes release selection, implementation evidence, and article review part of the writing workflow. It adds a dedicated Dev.to article experience, strengthens the generation pipeline, and revises how credentials move between the extension host, its webviews, and the CLI.

The work behind this update spans 65 changed or new files, including implementation, tests, documentation, dependency manifests, and build configuration. The useful result is what those changes let a developer do: choose a version, generate a technical draft from that version, inspect its formatting and code, and publish with a clearer understanding of what was checked.

What changes in the daily workflow?

DotShare already brings social and blog publishing into the editor. Version 3.5.2 expands the technical writing side of that workflow:

Area	Behavior in this update
Release selection	Choose a committed release, current committed work at HEAD, or tracked uncommitted changes explicitly.
Implementation context	Read release material from one resolved commit and include source excerpts with file and line information.
Article generation	Generate a Markdown draft with metadata, validate it, and use a bounded repair pass when needed.
Code examples	Verify excerpts against supplied source or documentation; flag and omit remaining unverifiable examples when the rest of the draft passes.
Dev.to review	Preview the title, description, tags, and rendered body together.
Saved credentials	Show 🔒 Key Saved & Active, with an empty replacement field available on demand.
CLI configuration	Store supported platform credentials in the OS credential store and keep preferences in the configuration file.

The developer still owns the final editorial decision. The checks make specific problems detectable; they do not establish the truth of every sentence an AI writes.

1. A release article needs a consistent version of the project

The first architectural change is the release boundary.

ReleaseRepository resolves the selected Git reference to a commit. That snapshot is then used for metadata, changelog content, release documents, source files, diffs, commits, and dependency comparisons. Reading these inputs from the same snapshot prevents a tagged release article from accidentally describing later local edits.

The distinction becomes visible in the UI:

• Committed release describes the selected tagged version.
• Current committed work (HEAD) can describe committed changes beyond the latest tag.
• Uncommitted changes describes tracked local edits as work in progress.

For example, if a repository contains a v2.1.2 tag and additional edits in the checkout, selecting v2.1.2 keeps those edits out of the release article. Choosing HEAD or uncommitted changes communicates a different scope.

The collector also explains incomplete history. A first tagged release without a previous release tag can include the complete committed tree. In an untagged repository, the committed comparison can be limited to the latest commit. Warnings help the author understand the material behind the draft instead of guessing from the version label.

Context is refreshed before generation, so an earlier modal preview is not silently treated as the final evidence set.

2. Workspace search follows the topic and the release boundary

A useful technical article needs more than the last few commit messages.

The context service can search Git history for terms from the selected topic. It combines commit-message matching with Git pickaxe searches for relevant code changes. Keyword extraction handles English and Arabic input, filtering conversational words so the search can focus on technical terms.

The same selected boundary also governs dependency comparisons. DotShare recognizes manifests for several ecosystems:

Ecosystem	Manifest
Node.js	package.json
Rust	Cargo.toml
Python	pyproject.toml
Go	go.mod

That lets an article distinguish a dependency upgrade in the chosen release from an unrelated edit in the current checkout.

Documentation adds another layer. Version-specific release files and relevant architecture or security documents can explain why a change exists. Multiline changelog notes are preserved so their meaning does not collapse into a handful of isolated bullets.

The collector limits document and source budgets and reports truncation. A truncated README is a visible limitation, not evidence that the entire document was reviewed. Architecture notes provide background; roadmap items do not establish that a feature has shipped. A verification document can also contain checks that remain unfinished, and the article should retain that distinction.

Active editor context is optional. A selected fragment can help identify the topic, but a local selection is labeled as a working-tree hint when writing about a committed release. It does not replace source read from the selected commit.

3. Code examples come from implementation excerpts

Technical articles are especially vulnerable to invented examples. A plausible function name or a convincing security check is easy to generate and hard to spot during a quick read.

DotShare now extracts source excerpts around added executable lines. The extractor looks for enclosing declarations and supplies the file path, line range, and whether the excerpt is partial. Ranking uses the release terms, identifiers, and changed code, while supporting helper or lifecycle methods can give a change the context it needs.

This is bounded source extraction using language-aware heuristics. It is not a full compiler analysis of every supported language.

The collector also reduces prompt noise by excluding material such as lockfiles, binary files, minified bundles, and test code from implementation examples. Python handling distinguishes executable changes from docstrings and test-oriented material.

After generation, a separate verifier checks fenced examples. Implementation examples must match a contiguous excerpt from the supplied evidence. Display normalization allows line-ending differences and a uniform dedent while preserving internal indentation, string literals, and the actual statements.

Reconstructing a function, inserting explanatory comments into its body, or joining unrelated pieces into a new example does not satisfy that rule.

Documentation examples and shell commands have their own evidence rules. Commands must be supported by supplied documentation or fit a narrow recognized checkout workflow. Changing a fence label to text does not provide a route around provenance checking.

Code is optional. An article that explains a supported change clearly can be more useful than one padded with an invented implementation.

4. Validation and repair have a defined stopping point

The generation flow has three main stages: create a draft, check detectable problems, and repair when necessary.

ReleaseContentValidator checks problems including:

• Empty output and unfinished code fences.
• Unsupported fenced code examples.
• URLs outside the exact selected call-to-action links.
• Source paths that do not appear in supplied evidence.
• Certain numeric claims about tests or diff statistics without supporting material.
• Missing or invalid Dev.to metadata.
• A generated draft that incorrectly sets published: true.
• Release prose that mixes in uncommitted work or exposes internal writing instructions.

The service makes at most two generation attempts. A validation problem can trigger one repair using the same evidence. The previous generated draft is identified as untrusted text rather than new evidence.

There is also a bounded recovery path for a response that reaches its output limit. A retry with a larger budget uses the remaining attempt; it does not start an unlimited series of retries and repairs.

Full Dev.to articles begin with a 6,000-token generation budget. The output-limit recovery can increase that budget up to 12,000 tokens. Technical deep dives and shorter posts use smaller budgets appropriate to their format. These are response budgets, not promises of an exact article length.

When an example still cannot be verified

Earlier behavior could end the entire generation flow with a code-validation error even when most of the article was usable.

The revised behavior is more precise. If the second attempt still contains closed, unverifiable code blocks, DotShare can omit those blocks and validate the remaining article again. When that article passes, the author receives a visible warning such as:

Omitted 1 code example(s) that could not be verified against the supplied evidence. Review the surrounding explanation before publishing.

A short standalone introduction to an omitted example can be removed with it. Other prose remains available for review.

The warning matters: removing a code block does not prove the neighboring explanation is correct. An unfinished fence, an unsupported URL, or another unresolved blocking error still prevents a successful result.

5. Provider completion is part of article quality

A successful HTTP request does not necessarily contain a complete article.

This update strengthens response handling across OpenAI, Claude, Gemini, DeepSeek, and xAI. Empty text is rejected, and provider-specific completion signals are checked before returning a draft.

Provider	Completion handling
OpenAI	Detect incomplete Responses API output and distinguish output-limit truncation.
Claude	Combine text blocks and detect token-limit stops or refusal.
Gemini	Check candidate finish reasons, including output-token exhaustion.
DeepSeek	Check completion finish reasons and reject empty content.
xAI	Check completion finish reasons and reject empty content.

Generation requests have explicit timeouts, and SDK retry settings are bounded where configured. The author gets an error for an incomplete response instead of a truncated article presented as finished.

Live model discovery remains the foundation introduced in the previous release. The improvements here build on it with stronger response handling and safer reuse of saved keys. Provider/model request identifiers also help prevent an older asynchronous response from replacing a newer selection in the UI.

6. Dev.to articles arrive as editable Markdown

The Dev.to workflow now has a dedicated DotShare AI Article action and a Full Article (Dev.to) writing tone. The result is Markdown with YAML frontmatter, ready to inspect and edit.

DotShare parses the metadata into separate publisher fields:

• Title.
• Description.
• Tags, normalized and limited to four.
• Optional cover image, canonical URL, and series when supplied.

The frontmatter is separated from the article body so the editor does not show metadata as prose. Generated content also receives publishing cleanup, including redundant opening titles and trailing hashtag lines where appropriate.

The article title belongs in the title field. Body sections can start at ##, which keeps the hierarchy consistent with Dev.to's article page. This follows the conventions in the DEV Editor Guide.

Canonical URLs receive special treatment: a repository URL is not automatically used as the article's canonical URL. The repository identifies the project; a canonical URL identifies the original publication of the same article. Authors can add that field when it actually applies.

The publisher retains both draft and publishing choices. Generating text is separate from deciding to publish it.

7. Live Preview includes the whole article header

Reviewing only the Markdown body misses part of the reader's first impression.

The updated Live Preview displays title, description, tags, then the article body, using the current editor values. Changes to the metadata fields update the preview without another AI request. Direction-aware text also helps with Arabic and mixed-language content.

marked renders the body and DOMPurify sanitizes the resulting HTML. The title, description, and tag labels are inserted as text rather than interpreted as HTML. The preview supports familiar Markdown structures such as headings, lists, tables, blockquotes, and fenced code blocks, with code styling suitable for review.

The UI includes word count, character count, and estimated reading time. They help authors judge the size of a draft without treating length as a measure of correctness.

Related webview changes escape content in thread composers, media thumbnails, draft cards, and scheduled-post attributes. Custom publish-button labels also survive UI refreshes.

Links respect the editor's decision

Web links appear blue and can be clicked during review. The webview sends an opening request to the extension host, which accepts ordinary HTTP or HTTPS URLs and calls the editor's external-link API.

This is the implementation in src/services/PreviewLinkService.ts:

export async function openArticlePreviewLink(value: unknown): Promise<boolean> {
    const url = getPreviewWebUrl(value);
    if (!url) return false;
    try {
        // Respect VS Code's result; a refusal must not trigger an alternate opener.
        return await vscode.env.openExternal(vscode.Uri.parse(url));
    } catch {
        return false;
    }
}

If opening is declined or throws an error, the action stops. There is no alternate opener. Local resources and command URLs are not accepted as external article links. In-article anchors are handled within the preview.

8. Saved keys stay on the extension host

Credential storage needed a review across the full workflow: platform configuration, AI model selection, saved API sets, migration, logging, and cleanup.

The extension uses context.secrets for sensitive values. That includes the Dev.to API key and the supported AI-provider keys. The browser-based webviews receive saved-status information instead of stored key values.

The status helper in src/security/credentials.ts returns booleans:

export async function credentialStatus(secrets: vscode.SecretStorage): Promise<Record<string, boolean>> {
    const status: Record<string, boolean> = {};
    for (const key of ALL_SECRET_KEYS) status[key] = !!await secrets.get(key);
    return status;
}

The UI shows 🔒 Key Saved & Active. It does not populate the old key into the field, even as a masked value. Change saved key reveals an empty replacement input, and leaving it blank retains the saved value.

Newly typed replacements necessarily pass through the input while the user is editing them. The important separation is that stored keys are not sent back from the extension host to fill the webview. Successful save acknowledgements clear replacement fields; closing the AI dialog discards pending replacements.

Saved AI keys can be reused for model discovery and generation without retyping them. A successful model-list request alone is not treated as proof that a new key was saved, and save failures do not receive a success acknowledgement.

Saved API configurations follow the same design. The host activates the selected credentials, while the UI gets metadata such as the configuration name and whether credentials are available. Snapshots are created from credentials already held on the host.

A saved key is scoped to its editor

VS Code and a separate editor application such as Antigravity have separate application storage. A key saved by DotShare in VS Code is not automatically available in DotShare running inside another editor.

The same key can be entered and saved in that editor separately. An empty saved-key status there does not, by itself, show that VS Code lost its stored key.

The extension relies on the host's SecretStorage implementation and its available storage backend. VS Code documents its API in the SecretStorage reference and Linux keyring configuration in its credential-storage troubleshooting guidance.

9. Migration and cleanup cover the credential lifecycle

Moving future writes into secure storage is only part of a migration. Older plaintext copies can remain behind.

The update migrates saved API configurations for every supported platform, including Dev.to. When a newer secure copy already exists, it is preserved and the stale legacy copy is removed. When no secure copy exists, the secure write precedes deletion of the old state.

Migration also handles the previous Discord webhook storage name and legacy API keys inside saved model-selection state. Model preferences can remain as preferences without retaining the key in ordinary state.

Local credential clearing covers platform keys, AI keys, GitHub and DotShare account secrets, saved configuration lists, relevant model preferences, and remembered cloud-sync consent. The UI receives cleanup notifications so the displayed state can follow the host.

Local cleanup is not cloud revocation. Credentials previously uploaded for scheduling must be revoked separately through the cloud service. That distinction is now stated in the user-facing security documentation.

10. The CLI stores credentials in the OS credential store

The extension's storage changes also exposed a separate CLI concern: a preferences file should not double as a credential vault.

The CLI now uses @napi-rs/keyring through a dedicated credential-store adapter. Its supported Telegram and LinkedIn credentials are stored under the DotShare CLI service in the native OS credential store.

The JSON configuration file contains preferences such as the server URL and default platforms. It is written through a temporary file and renamed, with a restrictive file mode requested on platforms that honor it. Credentials are read from the credential store when a command needs them.

For older configurations, the migration writes credentials to the native store before replacing the configuration with metadata. An existing secure value takes precedence over an older file copy. If keyring access fails, migration stops without erasing the legacy file or falling back to a new plaintext credential write.

The setter in src/cli/credential-store.ts makes the failure behavior explicit:

    set(platform: string, value: string): void {
        try {
            rememberSecret(value);
            new Entry('DotShare CLI', platform).setPassword(value);
        } catch {
            throw new Error('Could not save credentials in the OS keyring. No plaintext fallback was used.');
        }
    }

CLI logging is separated from VS Code-dependent logging, so command-line diagnostics can use redaction without requiring the editor runtime.

11. Logs and cloud sync have narrower, clearer behavior

This update removes sensitive logging of complete OAuth callback URLs and credential values from the reviewed paths. A shared redaction layer remembers secrets obtained from or written to SecretStorage and masks known values and common token patterns in diagnostic messages. Snippet sanitization also reduces the chance of common credential formats entering external AI requests.

Git commands use execFile with structured argument arrays. That avoids shell interpretation of topic text and path arguments and improves handling of platform-specific quoting. It is a concrete protection for Git subprocess calls, not a general claim that all inputs are safe.

Cloud scheduling has an explicit boundary as well. Credential synchronization checks saved user consent and requires HTTPS before reading local credentials for upload. Consent text explains that the server receives credentials to run scheduled posts.

The security documentation no longer presents unverified backend encryption claims as guarantees. Local SecretStorage protects the local workflow; it does not establish how a deployed server stores its copy.

Redaction and migration also have practical limits. Pattern matching cannot identify every possible secret, historical logs are not automatically rewritten, and removing a local copy does not rotate a token that was previously exposed.

12. The saved-key controls now follow the editor theme

The saved-state design should look deliberate, too.

The Change saved key control now has a dedicated CSS class in both the sidebar and the AI modal. It uses VS Code theme colors, rounded borders, a hover state, and a visible keyboard-focus outline. Hidden controls stay hidden through the CSS rule as well as their UI state.

That fixes the unstyled native button previously shown beside the saved-key badge and makes credential replacement fit the rest of the extension.

13. Build and test changes support the release

The update targets VS Code ^1.90.0, with matching API type definitions. Build, webview type-checking, lint configuration, dependency manifests, and packaging exclusions were adjusted alongside the implementation. Development artifacts and source-only material are excluded from the packaged extension where configured.

The automated suite was rerun for this article: 157 tests passed across 17 suites.

The coverage includes release boundaries and evidence extraction, generation validation and repair, provider completion signals, preview-link handling, credential status and migration, AI-key behavior, redaction, cloud-consent checks, and CLI configuration migration.

Those tests exercise deterministic behavior and mocked integrations. Native keyring persistence across an editor restart, live provider responses, Dev.to publishing, and deployed backend behavior remain separate integration checks. The passing suite is evidence for the tested implementation paths, not a production security certification.

Install or download DotShare

• Install from the Visual Studio Marketplace.
• Install from Open VSX in editors that use that registry.
• Download the latest available VSIX from the Marketplace for manual installation.

To install the downloaded file, open the Extensions view, select Install from VSIX… from its menu, and choose the package. Check that the installed version is 3.5.2 to use the behavior described in this article; the latest version available can differ between registries while an update is being published.

Try the article workflow on a real release

Start with a project that has useful release notes and a committed version to describe:

1. Save an AI-provider key and choose an available model in DotShare.
2. Open the Dev.to Article Publisher and select DotShare AI Article.
3. Choose the release scope and version deliberately.
4. Enable the relevant changelog and Git sources, and add an optional topic or editor hint.
5. Choose Full Article (Dev.to), language, selected links, and whether to include verified code excerpts.
6. Generate the draft and inspect any context or validation warnings.
7. Review the title, description, tags, links, and body in Live Preview.
8. Save a Dev.to draft, make the final editorial edits, and publish when ready.

DotShare 3.5.2 puts the version, the evidence, and the draft in the same workflow. It helps authors spend their review time on the actual explanation: what changed, why it matters, and what the implementation supports.

The code is available in the DotShare repository. Which part of writing release articles costs you the most time: finding the changes, explaining the implementation, or preparing the final post?