# LinkedIn Pulse Review Audit — 2026-08-02

## Scope

This note audits the Pulse pass associated with:

- Workflow: `Workflow/linkedin`
- Pulse run: `schedule-manual--4e78513d_1785686558465488000`
- Target workflow run: `iteration-0/engage`
- Target run completed: `2026-08-02T17:01:42Z`
- Reviewers run: `bug_review`, `artifact_review`, `eval_health`, `stores_health`, `goal_advisor`
- Reviewers skipped: `llm_ops_review`, `report_health`, `strategy_auditor`

The audit answers four questions:

1. Which reviewer created each class of registered issue?
2. Is each issue relevant and correctly classified?
3. How much duplication or lifecycle noise exists in the backlog?
4. How much time and token usage did each reviewer consume?

## Executive assessment

Pulse registered 42 records. They do not represent 42 independent bugs.

The reviews found several important correctness defects, particularly in Bug Review and Eval Health. However, the backlog is inflated by cross-review duplicates, transient validation failures that remained filed after repair, operational state recorded as issues, and strategy proposals shown alongside defects.

The main quality problem is therefore no longer reviewer reasoning. It is finding normalization, deduplication, classification, and lifecycle closure.

The five reviewers spent 1 hour 13 minutes 50 seconds actively running. Because they ran sequentially with gaps, the complete reviewer window was about 1 hour 25 minutes 54 seconds. Their cumulative model accounting was 35,356,816 tokens, but 33,942,528 input tokens were cached. Fresh input was 1,260,825 tokens.

## Registered record totals

### By creator

| Creator | Records | Assessment |
|---|---:|---|
| Artifact Review | 10 | Generally sensible evidence, but six records duplicate other reviewers |
| Bug Review | 8 | Strongest review; all eight findings were legitimate |
| Eval Health | 8 | Mostly valid; mixes correctness defects with optimization and coverage proposals |
| Stores Health | 7 | Mostly valid; one finding relied on an outdated knowledgebase-field assumption |
| Goal Advisor | 3 | Sensible strategic analysis; only one item is an implementation defect |
| Runtime and pre-validation | 6 | Mostly transient evidence, operational state, or duplicates rather than independent bugs |
| **Total** | **42** | Not 42 unique defects |

### By current lifecycle state

| State | Count |
|---|---:|
| `verification_inconclusive` | 15 |
| `proposal_recorded` | 7 |
| `awaiting_run` | 7 |
| `filed` | 6 |
| `closed` | 4 |
| `external_action_required` | 2 |
| `awaiting_user` | 1 |
| **Total** | **42** |

The UI's open-like count of 22 is composed of 15 `verification_inconclusive`, six `filed`, and one `awaiting_user` record. It should not be interpreted as 22 unrelated repairable bugs.

## Issue types and relevance

### 1. Correctness and runtime defects

These are real workflow bugs whose observed behavior violates the workflow contract. Bug Review found the clearest examples:

- Old LinkedIn profile selectors wasted 31 of 40 profile views. This was fixed and closed after the next run successfully extracted 15 of 15 headlines.
- Retired follow-candidate processing continued to run.
- Relative-time parsing matched `m` before `mo`, allowing months to be interpreted as minutes.
- The scan timestamp was captured late and local time was labelled as UTC.
- Semantically irrelevant targets, including medical and certification posts, passed the relevance filter.
- Malformed browser envelopes caused challenge detection to fail open.
- Pre-validation checked structural JSON shape but missed freshness, timestamp, and relevance errors.
- Generic whole-page text containing `security check` could create a false 24-hour automation block.

Assessment: all are relevant. Seven remain unverified because the producing LinkedIn workflow has not run since the repairs.

### 2. Evaluation correctness and measurement gaps

Eval Health found these correctness issues:

- Publishing evaluation still referenced retired Buffer and JSON behavior.
- Saved evaluator scripts were stale.
- Evaluation could inspect mutable current workspace state instead of the target run.
- Evaluator results lacked a consistent evidence and `max_score` contract.
- The evaluation allowed 150–400 words while `soul/soul.md` specifies 150–350 words.

Assessment: these are relevant correctness defects. The 350-versus-400 mismatch should be handled as a contract repair rather than merely a proposal.

Eval Health also raised broader improvements:

- Explicitly select a cheaper model tier for evaluation.
- Measure follower and inbound-comment trends, grounded relevant comments, theme compliance, and consumption of winning signals.
- Separate operational tactic checks from actual goal achievement.

Assessment: these are useful, but they are optimization or evaluation-design proposals, not bugs.

### 3. Artifact and configuration drift

Artifact Review reported ten records. Six describe real problems but duplicate canonical findings already created by Bug Review, Eval Health, or Stores Health:

- Weak semantic target validation.
- Retired follow-candidate work.
- Incorrect scan timestamps.
- Retired Buffer/JSON evaluation behavior.
- Stale evaluator scripts.
- Oversized duplicated workflow skill instructions.

Assessment: the evidence is relevant, but these should have been linked as corroborating evidence rather than filed as separate issues.

The remaining Artifact Review records were:

- Artifact Sync Cursor absent from `builder/improve.html`.
- Changelog entries omit some evaluation and learning edits.
- Explore and Measure work have no schedules, leaving promotion, performance refresh, and follower sampling unreachable.
- Global research refers to deleted web-search routes and `web_search_raw` behavior.

Assessment: these are reasonable findings. The first two are platform/dashboard gaps. The latter two are workflow-design or reachability decisions and may require user policy rather than an automatic repair.

### 4. Store, database, knowledgebase, and retained-state issues

Stores Health reported:

- Some `image_assets` rows pointed to volatile run-folder paths.
- The root workflow skill had grown into a duplicated 656-line instruction body.
- The database README omitted framework-managed tables.
- Deprecated safety and engagement guidance referenced retired storage formats.
- Protected voice and AgentWorks rules live in auto-maintained notes instead of clearly user-owned context.
- Step ownership and least-privilege database access were insufficiently explicit.

Assessment:

- Volatile image paths, oversized duplicated skills, incomplete database documentation, and retired storage guidance are relevant.
- The location of protected voice rules is a design decision; `awaiting_user` is appropriate.
- The database least-privilege concern was valid.
- The claim that an absent `knowledgebase_write_method` was itself a defect was outdated. That field is retired and intentionally absent under the current contract.

### 5. Strategy and goal gaps

Goal Advisor reported:

- Approval controls contradicted one another: the resolver did not approve, the parent required approval, and a worker could force live behavior after exact approval.
- The workflow lacks a bounded comparison of ordinary posts against participant-seeded posts.
- Existing evidence does not establish a clean causal link between broadcast or engagement activity and inbound comments or follower growth.

Assessment:

- The approval-control contradiction is a real implementation defect and has been repaired, but still awaits a producing run.
- The other two items are valid strategy and experiment proposals. They should remain separate from the bug backlog.

### 6. Runtime and pre-validation events

Six records came from evaluators or the engagement scan rather than the five review modules:

- The configured `workflow_db` route was unavailable, but the fallback database query succeeded.
- `automation_safety` contained a challenge and `blocked_until` value.
- The engagement scan initially omitted `posts_examined`.
- Seven follow candidates appeared despite the allowed maximum being zero.
- A text-only challenge appeared at a normal LinkedIn URL.
- The engagement scan initially omitted `notes`.

Assessment:

- Successful database fallback is operational telemetry, not a workflow issue.
- A current safety block is state/evidence, not an independent defect.
- The text-only challenge duplicates the canonical challenge-detection finding.
- Missing fields that were subsequently repaired should close automatically.
- Forbidden follow candidates are evidence for the retired-follow bug, not a new issue.

## Reviewer-by-reviewer quality assessment

### Bug Review

High relevance and good evidence quality. It identified concrete behavioral failures with clear expected and observed outcomes. Its active findings should remain canonical.

### Artifact Review

Good at collecting corroborating evidence, but poor cross-module deduplication caused six duplicate records. It also mixes workflow defects with platform-owned dashboard and changelog gaps.

### Eval Health

Mostly correct and valuable. Its defect findings are strong, but optimization and coverage recommendations should be typed separately from correctness issues.

### Stores Health

Mostly correct. One part of the step-config finding was based on a retired field and should not have survived current-contract validation.

### Goal Advisor

The reasoning is useful and appropriately cautious. Its strategy proposals should not contribute to a count presented as repairable bugs.

### Runtime/pre-validation filing

This is the weakest source of backlog quality. The system is retaining transient gate failures and observations rather than linking them to canonical findings or closing them after successful repair.

## Runtime and token usage

All five reviewers used `gpt-5.6-sol`. The terminal UI sometimes displayed a generic `Claude Code is working` status, but the underlying Codex rollout records identify the actual model as `gpt-5.6-sol`.

| Reviewer | Wall time | Input tokens | Cached input | Fresh input | Output tokens | Total tokens |
|---|---:|---:|---:|---:|---:|---:|
| Bug Review | 13m 06s | 6,489,875 | 6,262,784 | 227,091 | 28,182 | 6,518,057 |
| Artifact Review | 18m 43s | 8,107,760 | 7,833,344 | 274,416 | 38,414 | 8,146,174 |
| Eval Health | 13m 26s | 5,254,888 | 5,033,728 | 221,160 | 29,090 | 5,283,978 |
| Stores Health | 16m 33s | 8,545,417 | 8,271,872 | 273,545 | 33,262 | 8,578,679 |
| Goal Advisor | 12m 02s | 6,805,413 | 6,540,800 | 264,613 | 24,515 | 6,829,928 |
| **Total** | **1h 13m 50s** | **35,203,353** | **33,942,528** | **1,260,825** | **153,463** | **35,356,816** |

Token interpretation:

- Approximately 96.4% of input tokens were cache reads.
- The 35.36 million total is cumulative accounting across many agent turns, where context is repeatedly presented to the model. It is not 35 million newly processed uncached tokens.
- Fresh input was still substantial at approximately 1.26 million tokens.
- Artifact Review was the slowest reviewer.
- Stores Health consumed the most tokens.
- Reviewers ran sequentially. Their active time totalled 1h 13m 50s; gaps increased the first-review-to-last-review wall window to approximately 1h 25m 54s.
- Skipped modules consumed no reviewer runtime or tokens in this Pulse pass.

Token usage was read from the final `token_count` event in the five matching Codex rollout records under `~/.codex/sessions/2026/08/02/`. Wall time was measured from the corresponding Pulse terminal lifecycle.

## Fixer resolution audit

### Did the fixer fix every registered issue?

No. It made real source/configuration changes for most automatically repairable canonical defects, but it did not and should not treat every registered record as a repairable bug.

The 42 records currently divide into four practical groups:

| Practical outcome | Count | Meaning |
|---|---:|---|
| Closed | 4 | One fix was verified immediately; three findings were closed because fresh evidence showed no current change was required |
| Real changes awaiting proof | 16 | Fifteen canonical findings are `changed_unverified`; the approval-control repair is `awaiting_run` |
| Duplicate records linked to canonical changes | 6 | Artifact Review duplicates were not separately changed; they await the same producing-run proof as their canonical findings |
| Not resolved by the fixer | 16 | Seven proposals, two platform handoffs, one user decision, and six raw runtime/pre-validation filings |
| **Total** | **42** | |

This means the fixer performed substantive work, but only four records reached a terminal closed state. Source changes are not equivalent to verified resolutions.

### Exact resolution types

| Resolution type | Count | Interpretation |
|---|---:|---|
| `fixed_verified` | 1 | The fixer changed the artifact and proved the repaired result immediately |
| `verified_no_change` | 3 | Current evidence showed the reported behavior was already absent or no longer affected the live path |
| `changed_unverified` / current event `verification_inconclusive` | 15 | Files changed and static/inert checks passed, but a real producing workflow/evaluation run is still required |
| `awaiting_run` | 7 | Six cross-review duplicates point at canonical pending repairs; one approval-control repair needs a real approved Post run |
| `proposal_only` | 7 | Intentionally not applied because it changes strategy, rubric meaning, cadence, or source policy |
| `external_action_required` | 2 | Owned by the dashboard or shared platform rather than the workflow fixer |
| `awaiting_user` | 1 | Requires a user decision about the authoritative scope of protected voice/AgentWorks rules |
| Raw `filed` | 6 | Runtime/evaluator observations remain untriaged and were not resolved by the fixer |
| **Total** | **42** | |

### What the fixer actually changed

The changes are present in workflow commit `fd7a30f` (`pulse: back up review and maintenance state`). That commit changed 16 files, with 1,598 insertions and 2,028 deletions. The substantive changes include:

- Scanner contract repairs for challenge provenance, UTC scan start, `mo` before `m`, relevance evidence, semantic validation, and retired follow work.
- Approval-path changes in `step-post-approval-resolve`, `step-p4-publisher`, and the publishing worker so a fresh exact-draft approval and atomic claim control the live path.
- Target-run and group binding for publish and draft evaluation.
- Removal of four stale saved evaluator scripts.
- Explicit lower-tier agentic evaluator configuration.
- Evidence and exact `max_score=10` validation across ten evaluators.
- Replacement of the oversized global skill body with a 43-line selective index.
- Database README coverage for the missing Pulse lifecycle tables.
- Read-only drafter database access and explicit writer ownership.
- Future image generation changed to persist bytes under `db/assets/` with size and SHA-256 before writing the SQLite path.

The module audit recorded:

| Module | Result | Changed files | Verification state |
|---|---|---:|---|
| Bug Review | `changed` | 2 | Runtime proof awaits the next safety-permitted Engage run |
| Eval Health | `changed` | 6 | Evaluation runtime proof awaits a new applicable evaluation |
| Artifact Review | `done` | 0 | Reconciled duplicates, proposals, and external ownership |
| Stores Health | `changed` | 7 | One repair verified; three changes await real consumers |
| Goal Advisor | `done` | 0 | Strategy proposals preserved; approval repair recorded as an operational handoff |

### What is genuinely verified

Only `PUL-C7FDCD96` is `fixed_verified`. The fixer updated `db/README.md`, compared it with the live SQLite schema, and proved that all non-internal tables have documentation and ownership coverage.

Three records are `verified_no_change`:

- The deprecated headline selectors were not used by the current path and the fresh run populated 15 of 15 target headlines.
- The corresponding Stores Health headline record was the same resolved behavior.
- Current safety and engagement guidance already used SQLite instead of the deprecated JSON consumers.

These closures are legitimate, but two headline records represent the same underlying behavior.

### What changed but is not yet verified

Fifteen canonical findings have real edits plus successful structural or inert checks:

- Seven Bug Review findings covering scanner safety, time parsing, relevance, validation, and retired-follow behavior.
- Five Eval Health findings covering model configuration, stale evaluator code, publish evidence, target-run binding, and result schema.
- Three Stores Health findings covering the global skill index, step access/ownership, and future image durability.

The verification records explicitly say no post-change LinkedIn-producing run, applicable evaluation, normal workflow-step consumer, or image-producing Post has run yet. Their `verification_inconclusive` state is therefore correct.

### Approval-control repair lifecycle inconsistency

The approval-control defect `PUL-4A9661D7` was changed in `planning/plan.json`, and the changelog records modifications to the resolver and publisher control path. An inert six-case gate model and structural consistency check passed.

However, its attempt `fix-a4509c7516db6bd9` still has:

- attempt status: `fixing`
- `completed_at`: empty
- `changed_files_json`: empty
- no attempt-scoped verification record

The finding itself says `awaiting_run` and refers to the same attempt. This is a real lifecycle-recording bug: the implementation changed, but attempt completion, changed-file evidence, and finding transition were not committed atomically.

### Items intentionally not fixed

Seven proposal-only records were preserved:

- Add Explore/Measure schedules.
- Decide whether global web research remains part of the source policy.
- Change the draft hard gate from 150–400 to the soul contract of 150–350.
- Reweight tactic checks versus business outcomes.
- Expand evaluation coverage for actual goal measures.
- Run a participant-seeded comparison experiment.
- Establish a causal comparison for channel-driven follower/comment growth.

Most are correctly approval-gated. The 150–400 versus 150–350 mismatch is more questionable: the stable soul contract already says 150–350, so retaining 400 as the hard gate leaves a known correctness mismatch rather than a purely strategic choice.

Two platform-owned issues remain external:

- Artifact Sync Cursor missing from the Dashboard-owned `builder/improve.html`.
- The shared changelog model does not cover all evaluation and learning mutations.

One Stores Health question remains with the user: where protected voice and AgentWorks rules should be authoritative.

### Incomplete or stale remaining work

- Six raw runtime/pre-validation records remain merely `filed`; several should have been linked or automatically closed.
- Historical `image_assets` rows were deliberately not migrated. The future writer was repaired, but old absolute run-folder paths remain in SQLite.
- The dashboard remains stale because its 21-item count did not match SQLite's 22-item open-like count.
- The approval attempt remains stuck in `fixing` despite the corresponding plan changes.
- No post-fix producing run has yet converted the 16 changed findings into verified passes or failures.

### Resolution conclusion

The fixer did real and generally sensible implementation work. It did not fix everything, and the current database correctly avoids claiming that it did. The most accurate summary is:

- 1 changed and verified.
- 3 closed from fresh no-change evidence.
- 16 genuinely changed but awaiting real-run proof.
- 6 duplicate records tied to those pending changes.
- 16 proposal, external, user-decision, or raw-filed records remain unresolved.

The next meaningful verification step is a safety-permitted Engage/Post producing run followed by reviewer verification against the existing backlog. It should not create reworded duplicate findings.

## Pulse lifecycle and presentation problems exposed by this run

### Cross-review deduplication is insufficient

Artifact Review registered six issues already owned by other reviewers. Identity should be based on affected behavior, expected outcome, and observed failure. Corroborating evidence should append to the canonical issue.

### Temporary failures remain filed

Pre-validation concerns such as missing fields remained visible after the agent repaired the artifact and the final gate passed. These should close automatically or become attempt evidence.

### Observations are being treated as defects

Safety state and successful fallback behavior were filed alongside repairable bugs. They should be telemetry or evidence linked to a finding.

### Proposals and defects share one backlog presentation

Strategy hypotheses, measurement proposals, platform gaps, user decisions, and correctness bugs currently inflate the same headline count. The UI should expose their different types and owners.

### Verification is waiting on a producing run

The reviewed Engage run occurred before the Pulse fixes. The repaired behavior therefore has not executed yet. `verification_inconclusive` and `awaiting_run` are accurate for those repairs; they should not be described as failed fixes.

### One fix-attempt lifecycle appears inconsistent

The approval-control attempt `fix-a4509c7516db6bd9` remains recorded as `fixing` without `completed_at`, even though its finding is `awaiting_run` and the module reports the repair as applied. Attempt and finding state should transition atomically.

### The generated dashboard is stale

The dashboard stage wrote 21 open items while SQLite contained 22. Contract validation failed, the previous `builder/improve.html` was restored, and the visible dashboard therefore shows older July-era counts. The SQLite finding tables are the source of truth for this audit.

## Recommended system corrections

1. Use one canonical issue per affected behavior across all reviewers.
2. Append reviewer evidence and recurrence to that issue instead of filing duplicates.
3. Give every record an explicit type: defect, verification, proposal, platform gap, user decision, or telemetry.
4. Auto-close transient pre-validation findings after the repaired artifact passes its final gate.
5. Store safety state and successful fallbacks as observations, not open findings.
6. Keep strategy proposals and user decisions out of the repairable-bug headline count.
7. Make attempt-state and finding-state updates atomic.
8. Derive dashboard counts directly from the same canonical SQLite query used by validation.
9. Consider parallelizing independent read-only reviewers after shared resource and rate-limit behavior is verified.
10. Track reviewer wall time, fresh input, cached input, output, tool calls, and cost as first-class Pulse run metrics.

## Final conclusion

The review pass was valuable: it found genuine LinkedIn automation, evaluation, data-retention, and approval-control defects. Bug Review and Eval Health provided the most actionable correctness evidence.

The raw backlog count is nevertheless misleading. It combines real bugs with duplicates, proposals, platform handoffs, user decisions, transient validation events, and operational observations. Pulse should retain all of that evidence, but present and count it according to type and canonical issue identity.