## Opening the code parsing workspace and understanding what you can upload
In Atloria, open your project workspace and go to the **Code Parsing Workspace** from the technical documentation area. If you already worked through [Using Code Parsing to Support Technical Documentation](doc:using-code-parsing-to-support-technical-documentation), this is the point where you move from planning to actually adding source material and running a parse.

When the workspace opens, focus on four main areas:

- the **upload area**, where you add source files
- the **snippet input area**, where you paste code directly
- the **parse run status** area, where you watch progress
- the **results area**, where Atloria shows the parsed output you can use in documentation

Use **Upload** when you want Atloria to examine real project files together. This is the better choice when you need a broader picture, such as understanding a feature across several files, tracing related screens, or reviewing how a project section is organized. File uploads usually give you more context, which helps when you are writing feature explanations, technical reference pages, or workflow descriptions.

Use the **snippet** option when you only need to inspect one focused piece of code. This works well for quick research, such as checking a single screen, a small configuration block, or one reusable UI element before writing about it. A pasted snippet is faster to test, but it may show less surrounding context than a full file upload.

The parsed output helps you turn source material into documentation-ready inputs. In practice, that means you can use the workspace to discover project sections, identify screen names and relationships, and review implementation details before drafting user guides or technical pages.

[SCREENSHOT: Code Parsing Workspace showing upload area, snippet box, run controls, status area, and parsed results panel]

## Preparing files and snippets before you start a parsing run
Before you click **Parse**, take a minute to prepare the source material you plan to add. Clean inputs make the results easier to review and more useful when you start writing documentation.

If you are uploading files, choose the files or folders that match the documentation task in front of you. For example:

- For a feature walkthrough, select the files tied to that feature’s screens and related pages
- For a technical reference draft, include the files that define the feature structure and supporting pieces
- For broader discovery, upload a small group of related files instead of an entire codebase at once

Try to avoid uploading a large unrelated set of files just because they are available. In Atloria, narrower and more intentional uploads usually make the results panel easier to read.

If you are pasting a snippet, include enough surrounding code for Atloria to understand what it is looking at. A few isolated lines often produce weak results. A better snippet usually includes the full block you want to study, along with nearby declarations or setup that explains how that block fits into the page or feature.

Choose your input method based on your goal:

| Documentation goal | Better input choice | Why |
|---|---|---|
| Feature discovery | Related file upload | Gives broader context across screens and sections |
| API or technical explanation | Focused file upload or larger snippet | Preserves structure and nearby definitions |
| Quick clarification | Snippet paste | Fast for checking one specific area |

Also confirm that you can access the project workspace and save shared work in the parsing area. If your team uses shared documentation workflows, make sure you are working in the correct project before uploading files so other writers and reviewers can find the same parsing results later.

## Uploading source files or pasting code snippets
Once your source material is ready, add it to the **Code Parsing Workspace** using either the file upload option or the snippet box.

### Uploading files
1. In the workspace, click the **Upload** control.
2. Select the source files you want to analyze.
3. Wait for the files to appear in the pending input list or preview area.
4. Review the file names before you continue.

After the upload finishes, confirm that every file you selected is visible in the workspace. If a file is missing, add it again before starting the parse. This quick check helps you avoid running analysis on an incomplete set.

### Pasting a snippet
1. Click into the **snippet input** area.
2. Paste the code you want Atloria to analyze.
3. Review the pasted content in the preview area.
4. Make sure the snippet starts and ends in the right place.

Snippet review matters. If you only paste the middle of a larger block, the results may be incomplete. When possible, include the full section you want to document so the preview reflects the real boundaries of that code.

If you notice a mistake before parsing, update the inputs right away. In the workspace, you can remove the wrong file, replace an outdated version, or clear and re-paste the snippet. It is better to fix the input list first than to sort through confusing results later.

Use the preview as your last checkpoint. Confirm:

- the correct files are listed
- the snippet contains the intended section
- the source material matches the feature or workflow you are documenting

[SCREENSHOT: Workspace preview showing uploaded files in a pending list and a pasted snippet ready for parsing]

## Starting a parsing run and monitoring its progress
After you confirm the files or snippet in the workspace, start the analysis from the main action controls.

1. Review the pending inputs one more time in the workspace preview.
2. Click the **Parse** action to begin the run.
3. Watch the run status area as Atloria processes the source material.
4. Wait until the status changes to a completed state before opening the results.

During the run, Atloria moves through visible status stages such as **queued**, **in progress**, and **completed**. These labels help you understand whether your request is waiting, actively being processed, or ready for review. If you are working with multiple files, the run may take longer than a small snippet, so the status area is the best place to check progress instead of guessing whether the workspace has stalled.

While parsing runs, Atloria prepares structured output you can reuse in documentation work. The goal is not just to display raw code again, but to organize what was found so you can review feature structure, identify important sections, and gather accurate details before writing.

If you change the source material after a run, start a new parse so the results match the latest version. For example, re-run parsing when:

- you replaced a file with a newer copy
- you expanded a snippet to include missing context
- you narrowed the upload to a smaller feature area
- your documentation scope changed and you added more related files

Do not rely on older results if the input has changed. In Atloria, the parsed output reflects the material included in that specific run, so refreshing the run is the safest way to keep your documentation research accurate.

[SCREENSHOT: Parse run status area showing queued, in progress, and completed states]

## Reviewing parsed results for documentation work
When the run finishes, open the **parsed results** area and review what Atloria extracted from your files or snippet. This is where the workspace becomes most useful for documentation planning.

Look first for the main structure Atloria discovered. Depending on what you uploaded, the results may help you identify:

- the overall file organization
- important named sections within the source
- related screens or reusable parts
- content that can support technical reference writing

For documentation work, use the results panel as a research view rather than a final draft. You are looking for accurate clues about how a feature is organized and what deserves explanation. This is especially helpful when you need to describe a workflow, explain how a screen fits into a larger project area, or confirm the names of visible sections before writing.

Full-file uploads usually provide deeper context than snippets. A broader upload can reveal how one screen connects to another, or how a feature is grouped across several files. Snippet parsing is still useful, but the results may be narrower because Atloria only sees the selected block. If the output feels too thin, that is often a sign that you need more surrounding source material.

As you review results, capture the findings that matter most to your draft, such as:

- the names of user-facing screens
- the order of steps in a workflow
- the relationship between a page and its supporting sections
- wording you want to validate before publishing documentation

This is also a good point to compare what you expected to find with what Atloria actually surfaced. If the results do not support your documentation goal, adjust the inputs and run parsing again rather than forcing weak findings into your draft.

## Using parsing output in your documentation workflow
The parsed output becomes most valuable when you turn it into a writing plan. In Atloria, use the results to connect source material to the documentation sections you need to create or improve.

Start by mapping the parsed structure to your planned documentation. For example, if the results show a login screen, registration screen, admin area, analytics page, and security page, you can use that structure to decide whether you need separate help articles, a workflow guide, or a reference page for each area. This keeps your documentation aligned with the actual product experience instead of relying on assumptions.

Parsed results are also useful for validating terminology. Before you write, compare your draft language with the names and labels surfaced in the workspace. This helps you describe screens consistently and avoid mixing internal wording with what users actually see in Atloria.

When several people contribute to the same project, keep the parsing work tied to the shared workspace so others can review the same source-backed findings. This is especially helpful when writers, project leads, and administrators all need to agree on feature boundaries or confirm which screens belong in a documentation set.

Run another parse whenever the source changes or your scope expands. Common examples include:

- a feature update adds a new screen or step
- you move from one-page research to a broader workflow
- your first parse answered one question but raised another
- you need stronger context before writing a technical reference page

If you are using parsing as part of a larger documentation effort, pair the results with your page planning and review process rather than treating the workspace as a one-time task. The next step is to look more closely at what was captured in the results and how complete that coverage is in [Reviewing Parsed Code Results and Reference Coverage](doc:reviewing-parsed-code-results-and-reference-coverage).

## Common issues when uploading or parsing code and how to fix them
Most parsing problems in Atloria come from the input you selected, not from the documentation workflow itself. When results look wrong or incomplete, start by checking the workspace inputs and run status.

If uploaded files do not appear in the workspace, confirm that the upload finished and that the files were added to the pending input list. If the list is empty, use **Upload** again and wait for the files to show in the preview before you click **Parse**.

If snippet results are incomplete, the pasted code is often too narrow. Instead of submitting a few lines from the middle of a block, expand the snippet so it includes the surrounding section. Adding the full block usually gives Atloria enough context to produce more useful results.

If a parse run does not finish or the output looks outdated, check the status area first. A run may still be **queued** or **in progress**. If the run completed but the results still reflect older content, remove the previous input, add the latest file or snippet version, and start a fresh parse.

If the results are technically correct but not helpful for writing, change the scope:

- switch from a tiny snippet to a related file upload when you need context
- narrow a large upload when the results are too broad
- focus on the files tied directly to the screen or workflow you are documenting
- re-run parsing after replacing outdated source material

A good rule is simple: if the results do not help you explain a real feature clearly, adjust the input until the parsed view matches the documentation question you are trying to answer.

## Overview
Use the **Code Parsing Workspace** in Atloria when you need source-backed input for documentation work. The workflow is straightforward: add files or paste a snippet, review the pending input, start a parse run, and study the results before you write.

The most important choices happen before parsing begins:

- choose **Upload** for broader feature or workflow research
- choose the **snippet** area for a focused question
- confirm the preview so you do not analyze the wrong material
- re-run parsing whenever your source changes

Keep the workspace centered on your documentation goal. If you are writing a feature guide, upload the files tied to that feature. If you are checking one small section, paste a snippet with enough surrounding context to make the result meaningful. After the run completes, use the parsed results to confirm structure, identify the right screen names, and gather accurate details for your draft.

This document focused on running the workflow from input to results. For a closer look at how to inspect what Atloria found and judge whether your parse covered enough of the source, continue with [Reviewing Parsed Code Results and Reference Coverage](doc:reviewing-parsed-code-results-and-reference-coverage).