Έλεγχος Μηχανικής Ιδιοκτησίας

Έλεγξε τη μηχανική σου ετοιμότητα με στοιχεία από μια εφαρμογή AI.

Introduction

30 Second Summary

An AI app can look polished in a demo while its inner workings remain hard to explain. That gap becomes obvious when an interviewer asks what happens after a user clicks a button.

In this project, you will audit one existing TypeScript AI application to test how independently you understand it. Your findings become docs/engineering-ownership-audit.md, a hiring-focused report with a role-specific 30-day plan.

What You'll Build

You'll open docs/engineering-ownership-audit.md to show exactly how one user action travels through your app, where its behavior breaks down, and which roles your evidence supports.

By the end of this project, you'll have:

An evidence-backed workflow trace you can use to explain one request from the interface through the API, AI service, data layer, response, and production behavior.
An observed boundary case that shows how the application detects, communicates, and recovers from failure.
A role-specific readiness plan that turns strict skill scores into three priorities, a dated 30-day plan, and one real outreach message.
Secret Mission: Submit one live application using only Level 2 or Level 3 claims backed by your audit.

Are there any prerequisites?

You need one existing TypeScript application that uses AI, an accessible source repository, and preferably a deployed version.

You also need a Windows computer with Visual Studio Code plus accounts for GitHub and LinkedIn.

Before We Start

A focused audit needs one application, one user workflow, and one employment outcome. Locking in that scope now gives every claim and piece of evidence a clear purpose.

Set Up the Evidence Workspace

Your scope statement gives the selected TypeScript AI application a clear test. The evidence still lives across the running application, its repository, and current hiring benchmarks.

This step brings those materials into one inspection workspace. Your audit report will hold the starting facts that every later claim must match.

In this step, get ready to:

Verify access to Microsoft Edge, GitHub, and LinkedIn.
Download the repository as a ZIP archive and open the extracted source snapshot in Visual Studio Code.
Create the audit report with your scope details and current hiring benchmark links.

Verify your browser and accounts

The audit needs access to deployed behavior, source code, and live job benchmarks. Confirm those surfaces before you assemble the report.

Press the Windows key to open Windows search.
Type Microsoft Edge.
Press Enter to open the browser.

✔️ Microsoft Edge opens

Microsoft Edge is ready for the deployed application, repository, and hiring benchmarks.

ⓧ Microsoft Edge is unavailable

Install Microsoft Edge from the official Windows download page before continuing.

Open the official Download Microsoft Edge page.
Select the Windows download option.
Complete the installation using the installer prompts.
Use Windows search to open Microsoft Edge after installation.

You should see a Microsoft Edge window ready for browsing.

Microsoft Edge Still Won't Open?

Confirm that the installer finished before searching for Microsoft Edge.
Restart Windows if the completed installation does not appear in search.

Ask for help with the installation details that you can safely share: Help me diagnose why Microsoft Edge will not open after installation on Windows.

Go to the GitHub repository page for your selected application in Microsoft Edge.
Sign in to GitHub if prompted.
Open a new Microsoft Edge tab.
Go to LinkedIn in the new tab.
Sign in to LinkedIn if prompted.
Open the deployed application in another Microsoft Edge tab if a deployed URL is available.
Leave the repository page open for the source download.
Skip the deployment tab when the application has no deployed URL.

Good, your browser now holds the live surfaces that the audit needs to reference.

Download and open the source snapshot

A source snapshot lets you inspect the exact files behind your selected workflow. GitHub packages that snapshot into a ZIP archive for download.

Switch back to the GitHub repository tab in Microsoft Edge.
Select Code on the repository page.
Select Download ZIP.

Microsoft Edge should show that the repository ZIP archive has finished downloading.

Press Windows+E to open File Explorer.
Select the Downloads folder in the left sidebar.

You should see the downloaded repository archive with a .zip file extension.

Right-click the downloaded ZIP archive.
Select Extract All....

The extraction dialog shows where Windows will place the source snapshot.

Select Extract to create the extracted project folder.

File Explorer should open the extracted folder and show the repository files inside it.

What Does the ZIP Prove?

The ZIP archive contains a snapshot of the repository source. It gives you the files and symbols needed for code tracing.

The archive does not contain the complete repository history. Commit and pull request evidence remains on GitHub.

Press the Windows key to open Windows search.
Type Visual Studio Code.
Press Enter to open Visual Studio Code.
Select File from the top menu.
Select Open Folder....

The folder picker now lets you choose the extracted source snapshot.

A trust prompt can feel like a blocker. It controls whether the downloaded workspace can execute code.

Select the extracted project folder in the folder picker.
Select Select Folder.
Keep the workspace restricted if Visual Studio Code asks whether you trust the authors.

You should see the extracted project folder at the top of the Visual Studio Code Explorer.

Source Files Missing From the Explorer?

Use File and Open Folder... again if the Explorer shows the ZIP archive instead of extracted files.
Open the inner project folder if the extracted folder contains another folder with the application source.

Get help identifying the correct source folder: Help me find the correct extracted project folder to open in Visual Studio Code.

That's the source secured. You now have a local snapshot that can be inspected without changing the original repository.

Create the audit report

The audit report is a Markdown document stored beside the source. Its first section fixes the application scope before later investigation changes your understanding.

Inspect the Visual Studio Code Explorer to determine whether a docs folder already exists.
Use the folder creation control at the top of the Explorer to create docs if it is missing.
Select the docs folder in the Explorer.
Use the file creation control at the top of the Explorer.
Type engineering-ownership-audit.md as the file name.

The empty docs/engineering-ownership-audit.md file should open in the editor.

Fill each variable with evidence from your application and scope statement.
Seed docs/engineering-ownership-audit.md by copying this completed scaffold into the file:

# Engineering Ownership Audit

## Audit Scope

- Application: [[APPLICATION_NAME="your application name"]]
- Product purpose: [[PRODUCT_PURPOSE="the product outcome in one sentence"]]
- Target user: [[TARGET_USER="the primary user"]]
- Selected user workflow: [[SELECTED_WORKFLOW="the workflow you selected"]]
- Deployed URL: [[DEPLOYED_URL="https://your-app.example.com or Not available"]]
- Repository URL: [[REPOSITORY_URL="https://github.com/your-name/your-repository"]]
- Deployment environment: [[DEPLOYMENT_ENVIRONMENT="provider and environment, or Unknown"]]
- Primary role family: [[PRIMARY_ROLE_FAMILY="your selected role family"]]

## Current Hiring Benchmarks

### Applied AI Engineer
- [Early Career Consult Program - Associate AI Engineer](https://kyndryl.wd5.myworkdayjobs.com/en-US/KyndrylProfessionalCareers/job/USDALFRI---Dallas-Frisco-AI-HUB-FRI/Early-Career-Consult-Program---Associate-AI-Engineer_R-66739-2)

### Full-Stack Developer
- [Full-Stack Developer (.NET Core / Python / React / TypeScript)](https://trendmicro.wd3.myworkdayjobs.com/en-US/External/job/Full-Stack-Developer--NET-Core---Python---React---TypeScript-_R0010163)

### AI Integration Engineer
- [AI Solutions Developer, Associate/ Senior Associate](https://careers.ey.com/ey/job/AI-Solutions-Developer%2C-Associate-Senior-Associate-048583/1406871333/)
- [Forward Deployed Engineer, AI](https://careers.ey.com/ey/job/Toronto-Forward-Deployed-Engineer%2C-AI-Technology-Strategy-%26-Transformation-ON-M5H-0B3/1445311633/)

### Solutions Engineer
- [Partner Solutions Engineer, EMEA](https://vercel.com/careers/partner-solutions-engineer-emea-6132416004)
- [Customer Support Engineer](https://vercel.com/careers/customer-support-engineer-6230763004)

How Does This Scaffold Support the Audit?

The audit scope records the product, user, workflow, locations, environment, and employment target that your evidence must support.
The hiring benchmark links give later readiness decisions a current market reference.
Values such as Not available and Unknown preserve uncertainty instead of turning it into an unsupported claim.

Save docs/engineering-ownership-audit.md.
Press Ctrl+Shift+V while the audit file is active to open its preview.

You should see a rendered audit title, an audit scope section, and four hiring benchmark sections.

Audit Preview Missing Information?

Confirm that the file is named engineering-ownership-audit.md if Visual Studio Code shows plain text without a Markdown preview.
Confirm that the file appears inside the docs folder if the report is missing from the project Explorer.
Check every scaffold variable for an entered value if a scope field is blank.

Ask for help with the report structure: Help me diagnose why my engineering ownership audit Markdown preview is incomplete.

✔️ My Audit Has Everything

Your report now contains the required scope details and current hiring benchmark links.

ⓧ I'd Like to Double Check the Full File

# Engineering Ownership Audit

## Audit Scope

- Application: [[APPLICATION_NAME="your application name"]]
- Product purpose: [[PRODUCT_PURPOSE="the product outcome in one sentence"]]
- Target user: [[TARGET_USER="the primary user"]]
- Selected user workflow: [[SELECTED_WORKFLOW="the workflow you selected"]]
- Deployed URL: [[DEPLOYED_URL="https://your-app.example.com or Not available"]]
- Repository URL: [[REPOSITORY_URL="https://github.com/your-name/your-repository"]]
- Deployment environment: [[DEPLOYMENT_ENVIRONMENT="provider and environment, or Unknown"]]
- Primary role family: [[PRIMARY_ROLE_FAMILY="your selected role family"]]

## Current Hiring Benchmarks

### Applied AI Engineer
- [Early Career Consult Program - Associate AI Engineer](https://kyndryl.wd5.myworkdayjobs.com/en-US/KyndrylProfessionalCareers/job/USDALFRI---Dallas-Frisco-AI-HUB-FRI/Early-Career-Consult-Program---Associate-AI-Engineer_R-66739-2)

### Full-Stack Developer
- [Full-Stack Developer (.NET Core / Python / React / TypeScript)](https://trendmicro.wd3.myworkdayjobs.com/en-US/External/job/Full-Stack-Developer--NET-Core---Python---React---TypeScript-_R0010163)

### AI Integration Engineer
- [AI Solutions Developer, Associate/ Senior Associate](https://careers.ey.com/ey/job/AI-Solutions-Developer%2C-Associate-Senior-Associate-048583/1406871333/)
- [Forward Deployed Engineer, AI](https://careers.ey.com/ey/job/Toronto-Forward-Deployed-Engineer%2C-AI-Technology-Strategy-%26-Transformation-ON-M5H-0B3/1445311633/)

### Solutions Engineer
- [Partner Solutions Engineer, EMEA](https://vercel.com/careers/partner-solutions-engineer-emea-6132416004)
- [Customer Support Engineer](https://vercel.com/careers/customer-support-engineer-6230763004)

Before the final check, predict which setup facts the workspace can now prove.
Confirm that the Visual Studio Code Explorer shows the extracted project as the active workspace.
Confirm that the audit preview shows the product purpose, target user, and selected workflow.
Confirm that the audit preview shows the deployed URL, repository URL, deployment environment, and primary role family.
Confirm that each hiring benchmark section contains working posting links.

You should see the extracted project as the active workspace in the Explorer. The preview should show your application URL, repository URL, chosen workflow, role family, and benchmark links.

Your evidence workspace is ready. Next, you will explain the workflow from memory before the source can influence your story.

Defend the Architecture Independently

Your evidence workspace now frames the exact workflow this audit tests. It also names the hiring outcome your evidence must support.

A confident architecture story can feel like proof when it comes from memory. This step exposes the gap before source files or runtime evidence can influence your answer.

In this step, get ready to:

Explain the selected workflow using only observable application behavior.
Predict what happens behind the interface.
Convert every architecture statement into an unproven claim.

Write your unaided workflow explanation

An unaided explanation captures what you can currently reason through from observable behavior. Every hesitation reveals a useful gap.

Save your current changes in docs/engineering-ownership-audit.md.
Close every source-file tab in Visual Studio Code.

You should now see the audit as the only open editor tab.

Close every active code-search result.
Close every AI assistant window or panel.

Your editor should now show no implementation details or generated explanations.

Close every documentation page in Microsoft Edge.
Switch back to the running application in Microsoft Edge.

The running application is now your only technical reference.

What to explain from memory

Identify the interface event that begins the workflow.
Describe the API boundary that receives the request.
Describe the server logic that handles the request.
Describe the AI call that supports the workflow.
Describe the database interaction that you expect.
Describe the result returned to the interface.
Name the likely failure points.

Add an Unaided five-minute workflow explanation heading to docs/engineering-ownership-audit.md.
Start a five-minute timer.
Write continuously beneath that heading until the timer ends.
Save docs/engineering-ownership-audit.md.

You should see a complete explanation that follows the workflow from its first interface event to its returned result.

You have captured an honest baseline. The explanation now shows what you can defend without borrowed reasoning.

Predict hidden contracts and failure behavior

Predicted request shapes force your architecture story to become specific. Predicted security boundaries reveal where your understanding may depend on assumptions.

Add a Predicted contracts and behavior heading beneath your explanation.
Write the request shape you believe crosses the API boundary.

The new section should now name the fields that you expect the workflow to send.

Write the response shape you believe returns to the interface.
State where authentication most likely occurs.

Your prediction should now separate the incoming request from the returned result. It should also identify how the application recognizes a user.

State where the authorization decision most likely occurs.
Save docs/engineering-ownership-audit.md.

Authentication and authorization predict different controls

Authentication predicts how the application recognizes a user. Authorization predicts what that user can access or change.

Record the data you believe the application stores.
Record the data you believe reaches the external AI provider.

The audit should now show your predicted storage boundary. It should also show your predicted external data boundary.

Predict the user-visible result when the AI service fails.
Predict the user-visible result when the database fails.

You should now see two explicit failure predictions beneath the data-boundary notes.

Save docs/engineering-ownership-audit.md.

Turn every statement into an evidence claim

A claim table prevents confidence from quietly becoming evidence. Every row stays unproven until direct evidence supports it.

Add a Claim table heading beneath your predictions.
Create a four-column Markdown table beneath the heading.

You should now see one empty header row above the table body.

Label the first column Claim.
Label the second column Confidence.

The first two columns should now capture what you believe and how strongly you believe it.

Label the third column Required evidence.
Label the fourth column Status.

The table should now have all four fields required for evidence review.

Convert each statement from the unaided explanation into its own claim row.
Add each prediction as its own claim row.

Every architecture statement should now have a separate place in the table.

What counts as required evidence

The required evidence field names what you must inspect later. It does not grant proof by itself.

An exact file path.
An exact symbol name.
A test result.
A log entry.
A network observation.
A database artifact.
A deployment setting.

Record a confidence note for every row.
Name the direct evidence that would test every row.

Each row should now separate personal confidence from the evidence needed to verify the claim.

What the statuses mean

Use Unsupported when no direct evidence currently backs the claim.

Use Uncertain when the explanation contains ambiguity or contradiction.

Use Ready to verify when the claim names a specific evidence target. The claim still remains unproven.

Set every row to Unsupported, Uncertain, or Ready to verify.
Save docs/engineering-ownership-audit.md.

Before you read it aloud, make a mental prediction about whether any confident statement can count as proven at this stage.

Read your unaided explanation aloud for five minutes.
Inspect the completed claim table.
Match every spoken architecture statement to one claim row.
Check that every row uses one of the three allowed statuses.

You should see every statement marked Unsupported, Uncertain, or Ready to verify. No statement counts as proven yet.

That is the difficult baseline established. Your audit now separates independent reasoning from evidence you still need to collect.

Your architecture story now exposes every unsupported assumption. Next, you will test those claims against the source and observable runtime behavior.

Replace Claims with Engineering Evidence

Your unaided explanation turned assumptions into visible claims. Each unsupported claim now gives you a precise place to investigate.

A hiring-ready audit needs source evidence to agree with runtime behavior. This step replaces your architecture story with direct engineering evidence.

In this step, get ready to:

Trace the selected workflow through every source layer that exists.
Test one safe boundary input against a written prediction.
Review the controls that support production ownership.

Trace the workflow through source and runtime

An end-to-end trace follows one user input from the interface to the rendered result. Each present layer needs an exact file path plus a symbol name.

What makes a trace defensible?

A defensible trace identifies every present handoff. It also states which expected layers do not exist.

Interface evidence names the user event plus its handler symbol.
API evidence names the request construction plus the contract crossing the boundary.
Server evidence names the route symbol that receives the request.
Validation evidence names the check applied to the input.
Authentication evidence names the point where the application establishes identity.
Authorization evidence names the point where the application checks permission.
AI evidence names the provider integration plus the data sent to it.
Database evidence names the data-access symbol plus the affected data.
Error evidence names the handler for unsuccessful behavior.
Response evidence names the symbol that renders the final result.

Each trace row records the layer plus its file path. It also records the symbol name plus the input-to-output change.

The final field identifies whether the proof came from source or runtime.

Switch back to the local source snapshot in Visual Studio Code from earlier.
Run the selected workflow once in the available application environment from earlier.
Locate the exact symbol that handles the first interface event.
Follow the handled value through every present layer described above.
Add the trace table described above to docs/engineering-ownership-audit.md.
Record one evidence row for every present layer.

Your trace should now show every present hop from the user action to the rendered result. Each hop should point to a specific source location.

Mark every absent layer as Not present.
Attach the matching trace evidence to each claim that the source now supports.

Good work. Your architecture story now has a source-backed path that another engineer can inspect.

Can't connect two layers?

Search for the final user-visible text to trace the response path backward.
Search for a request field from the interface to find where the application constructs the API call.
Check imports plus call sites before marking a layer as Not present.

Ask for help without sharing proprietary source or credentials: Help me plan a source-tracing strategy for a TypeScript workflow when I cannot connect two layers.

Test one safe boundary case

A boundary test checks whether your mental model predicts real behavior. The first mismatch reveals where your understanding needs more evidence.

Select one invalid or boundary input that cannot delete data or alter live infrastructure.
Add a prediction record to docs/engineering-ownership-audit.md for that input.

Before you submit the input, do you expect the application to reject it or process it?

Submit the selected input through the deployed application in Microsoft Edge from earlier or through the project's documented non-production environment.

You now have a user-visible result to compare with your prediction. Treat the observed behavior as evidence even when it contradicts your explanation.

Can't complete the boundary test?

Use the project's documented non-production environment if the deployed application is unavailable.
Choose a different safe input if the first option could expose a secret or modify real data.
Avoid inventing a local start command when the repository does not document one.

Need help choosing a safe case? Help me design a non-destructive boundary test for my application.

Record the exact user-visible result in the audit.
Identify the first point where the observed behavior differs from your prediction.

Your test record now pairs a prediction with an observed outcome. That comparison is stronger than a claim based on memory.

Link the first difference to the exact code path that explains it.
Enter No difference observed if every predicted point matched the observed behavior.

You have now tested your understanding against real application behavior. The mismatch or confirmed prediction gives your audit runtime evidence.

Review production controls

A production claim needs evidence beyond the main success path. This review records what the repository or runtime proves about reliability and ownership.

What belongs in the control review?

Debugging evidence plus API contracts.
Database schema plus the complete data lifecycle.
Secret boundaries plus authorization evidence.
Input validation plus sensitive data sent to AI services.
Unit tests plus integration tests.
AI-output evaluation plus accuracy or reliability checks.
Deployment evidence plus application logs.
Monitoring evidence plus retry behavior.
Timeout behavior plus rollback evidence.
Incident ownership plus documented recovery responsibility.

README prose can point you toward evidence. A direct source path or runtime observation supports the final finding.

Add a control-review table to docs/engineering-ownership-audit.md.
Complete one finding for every control listed above.

The control review should now contain a dedicated finding for every production area. Empty spaces would hide gaps that hiring evidence needs to expose.

Cite an exact source or runtime artifact for every positive finding.
Enter No evidence found wherever the repository or runtime does not prove a control exists.

Every control now has either direct evidence or an explicit gap. Missing evidence remains visible instead of becoming an accidental production claim.

Revisit each production claim in the original claim table.
Label every production claim without direct control evidence as Unsupported.

Before you rerun the boundary input, do you expect the application to repeat the behavior you recorded?

Run the same safe boundary input again in the application environment from earlier.

You can now see whether the behavior is repeatable. A changed result becomes new evidence about nondeterminism or environment state.

Compare the new user-visible result with the result recorded in your audit.
Record any new difference beside the original boundary-test evidence.

The final audit check ties your source trace to observed behavior. It also keeps unsupported operational assumptions visible.

Review the trace for exact file paths plus symbol names in every present layer.
Review the trace for an explicit Not present finding in every absent layer.
Review the control table for evidence or No evidence found in every row.

You should see an evidence-backed path from the interface to the final result. No production claim should appear proven without a source link or runtime observation.

That's the evidence gap closed: your audit now shows what you can prove plus where ownership still breaks down. Next, you'll turn those findings into strict readiness decisions and a market-facing plan.

Score Readiness and Start the Market Loop

You have done the hard evidence work. Your audit now connects one TypeScript AI workflow to exact source files plus observed runtime behavior.

A single flattering score can hide a dangerous role-critical gap. Readiness must be decided per skill before you test it against live employers.

You will assign an evidence level to each engineering competency. You will then compare those levels with current roles.

Your final move is a dated 30-day plan plus one evidence-focused LinkedIn message. This starts the market-feedback loop today.

In this step, get ready to:

Assign strict evidence levels to ten engineering competencies.
Compare your audit with four current role paths.
Start a dated market loop built around evidence work, weekly applications, and outreach.

Score each competency with evidence

An evidence level measures what you can prove through source or runtime evidence. It keeps familiarity from receiving credit for independent ownership.

How the evidence levels work

Use 0 - Unverified when no direct source or runtime evidence supports the competency.
Use 1 - Assisted when you can complete the work with AI assistance or detailed guidance.
Use 2 - Independent when you can explain or perform the work using direct evidence from the application.
Use 3 - Operational when you also have evidence of safe modification, diagnosis, testing, or production ownership.

Switch back to docs/engineering-ownership-audit.md in Visual Studio Code.
Add a level 3 Markdown heading named Evidence Levels below the control review.
Create a table under that heading with the columns Competency, Evidence level, and Direct evidence.
Select the preview control in the upper-right corner of the editor.

You should see the new evidence-level heading plus an empty three-column table beneath your control review.

Add one row for code understanding, architecture, debugging, APIs, databases, security, testing, AI behavior, production operations, and technical communication.
Assign one of the four evidence levels to every row.
Return to the Markdown preview.

You should see ten competency rows with one evidence level assigned to each row.

Add exact source paths or runtime observations to every row scored 2 - Independent or 3 - Operational.
Record the missing proof beside every row scored 0 - Unverified or 1 - Assisted.
Return to the Markdown preview.

Every higher score should now point to direct evidence. Every lower score should show the exact ownership gap that remains.

Why there is no overall score

An average can bury a Level 0 in authorization, data handling, debugging, or production behavior. Keeping every competency visible protects you from making a broad readiness claim that one critical gap can disprove.

Compare your evidence with current roles

A role decision becomes useful when it compares employer requirements with your existing proof. Each path gets its own decision because the evidence threshold changes with the work.

How to map the four role paths

Applied AI Engineer emphasizes development, testing, deployment, support, troubleshooting, documentation, security, APIs, integrations, model evaluation, and monitoring.
Full-Stack Developer emphasizes React with TypeScript, APIs, backend development, databases, debugging, deployment, and CI/CD.
AI Integration Engineer uses current AI Solutions Developer plus Forward Deployed Engineer postings as market proxies for enterprise integration work.
Solutions Engineer remains a longer path unless a live junior or associate posting proves a closer entry point.

Add a level 3 heading named Role Matrix below the evidence scorecard.
Create a table with the columns Role path, Repeated requirements, Evidence match, and Decision.
Return to the Markdown preview.

You should see an empty four-column role matrix beneath the evidence scorecard.

Add rows for Applied AI Engineer, Full-Stack Developer, AI Integration Engineer, and Solutions Engineer.
Compare your evidence with the supplied current benchmark links for each row.
Return to the Markdown preview.

The matrix should now show four distinct role paths plus the requirements repeated across their benchmark postings.

Label every role path Direct fit, Stretch fit, or Later path.
Add one evidence-based reason beside every decision.
Return to the Markdown preview.

You should see one decision for every role path. Each decision should point back to evidence in your scorecard or to a clearly named gap.

Start the 30-day market loop

A useful 30-day plan produces evidence plus market feedback every week. Limiting the plan to three gaps keeps the work focused on requirements that employers repeatedly request.

Sending a real message can feel exposing. Your completed audit keeps every claim grounded in evidence.

Add a level 3 heading named 30-Day Plan below the role matrix.
Enter today's date beneath the heading.
Return to the Markdown preview.

You should see a dated plan section beneath the completed role matrix.

Select no more than three gaps from your lowest evidence levels.
Prioritize gaps that appear repeatedly across your target role postings.
Return to the Markdown preview.

The plan should now name up to three gaps. Each gap should connect a weak evidence level with a repeated employer requirement.

Create four weekly rows with space for evidence-building work, applications, outreach, and proof added to the audit.
Schedule at least one application plus one outreach action in every week.
Return to the Markdown preview.

You should see four weeks of evidence work paired with recurring applications plus outreach.

Return to LinkedIn in Microsoft Edge.
Select the Jobs icon.
Use the Search bar to search for your selected primary role family.
Apply filters that match your current location.
Open the details for one current role.
Confirm that the role matches your work-authorization situation.
Choose the role only after confirming both eligibility requirements.

You should now have one current role that you are eligible to pursue from your location.

Can't find an eligible role?

Search for one proxy title already included in your role matrix.
Remove one nonessential experience filter.
Keep your location plus work-authorization requirements unchanged.

If the results still do not fit, help me refine this role search.

Your outreach message only needs one verified strength plus one narrow question. A focused question gives the recipient something concrete to answer.

Choose a recruiter, hiring manager, or engineer connected to the current role.
Select a repository or deployed-application link that the recipient can open.
Draft a concise message that names the role, links the project, states one verified strength, and asks what evidence the team values most.
Remove every claim that your audit cannot support directly.
Send the message through LinkedIn.

You should see the message in your LinkedIn sent messages. This is the first external test of how your evidence lands with the hiring market.

Switch back to docs/engineering-ownership-audit.md.
Record the role title, job URL, message date, recipient type, verified strength, narrow question, and sent message.
Save docs/engineering-ownership-audit.md.
Before the final check, predict whether every role decision plus outreach claim has a direct evidence trail.
Return to the Markdown preview.
Return to your LinkedIn sent messages.

In the audit preview, you should see ten competency levels, four labeled role paths, a dated 30-day plan, and the current role with outreach details. In LinkedIn sent messages, you should see the concise message tied to that role.

You have crossed the line from self-assessment into market feedback. Your evidence now drives both skill-building plus outreach.

Secret mission

Submit an Evidence-Matched Application

Turn your audit into one truthful application for a live early-career role. Use only Level 2 or Level 3 evidence. Submit it to a real employer before logging the confirmation plus follow-up date.

Clean Up Your Resources

Choose the cleanup option that matches what you want to do next. Your local audit has no ongoing costs.

Resources you used:

The extracted local source snapshot from your GitHub repository.
The audit report at docs/engineering-ownership-audit.md inside the local source snapshot.

Keep everything running

Keep the snapshot when you want to strengthen the audit with new evidence. Local storage creates no project cost.

Retain the extracted source snapshot on your Windows computer.
Update docs/engineering-ownership-audit.md after each reliability improvement.
Add each future application outcome to the audit.
Record each employer response in the audit.

Pause - I'll come back to this later

Pausing keeps the audit local until you return. Sensitive application notes belong only in the local copy.

Keep the extracted source snapshot on your computer.
Remove sensitive application notes from docs/engineering-ownership-audit.md before committing a public version.
Return to the dated 30-day plan when you resume.

Delete - I don't want to use this again

Deleting the extracted folder becomes permanent after you clear the Recycle Bin. The change applies only to the local snapshot.

Close Visual Studio Code to release the extracted source snapshot.
Open File Explorer from Windows search.
Return to the location where you extracted the GitHub archive.
Select the extracted local source snapshot folder.
Delete the selected folder containing docs/engineering-ownership-audit.md.
Clear the deleted folder from the Recycle Bin.
Confirm the extracted folder is absent from its previous location.

Cleanup complete. The local source snapshot is now removed from your computer.

Your original GitHub repository remains unchanged. Your deployed application remains unchanged.

Nice Work!

You did it! Your TypeScript AI application now has a defensible engineering-readiness audit backed by direct evidence.

What you learned:

Built an evidence-backed workflow trace with exact files and symbols. The trace follows the chosen workflow from its interface event to its rendered result.
Tested a safe boundary case against the running application. You compared the prediction with the observed result. You documented the first point of difference.
Scored ten engineering competencies with a strict evidence scale. You converted those findings into role-specific decisions. You built a focused 30-day plan. You started the market-feedback loop with targeted outreach.
Secret Mission: Submitted one evidence-matched application using only Level 2 or Level 3 evidence. You saved the confirmation. You recorded the role in docs/engineering-ownership-audit.md. You added a follow-up date.

Ready to quiz yourself?