Thanks Yufei and Xi! This is really excellent work. The final product is clean and professional. Below are the grading components, followed by some feedback.

Grading

No code is used repetitively (no more than twice) [7/10 points]
More than one variant of purrr::map is used [10/10 points]
At least one {purrr} function outside the basic map family (walk_*, reduce, modify_*, etc.) [10/10 points] (this one was given freely)
At least one instance of parallel iteration (e.g., map2_*, pmap_*) [10/10 points]
At least one use case of tidyr::nest %>% mutate() [10/10 points]
At least two custom functions [20/20 points; 10 points each]
Code is fully reproducible and housed on GitHub [10/10 points]
No obvious errors in chosen output format [10/10 points]
Deployed on the web and shareable through a link [10/10 points]

Feedback

So I really feel like you've made the file directory stuff quite a bit more difficult than it needs to be. Specifically, if you use {fs} package, together with {here} (I'll try one more time to convince you) the code becomes much more readable and succinct.

simi_rtv_files <- dir_ls(here("derivatives"), 
                         recurse = TRUE,
                         regexp = "(?=.*retrieval)(?=.*zr_sim)(?=.*7-tmaps)",
                         perl = TRUE)

labels_files <- dir_ls(here("derivatives"), 
                       recurse = TRUE,
                       regexp = "(?=.*beh_)(?=.*pairwise)",
                       perl = TRUE)

simi_rtv_raw2 <- map2_df(simi_rtv_files, labels_files, read_simi)

identical(simi_rtv_raw, simi_rtv_raw2)
# [1] TRUE

This is a little complicated because of the regex but basically it's just an AND operator for different patterns you want to match. The regexp argument is just passed to grep, and so perl is passed to that, which is basically just a little more powerful regex operator. In your specific situation, you might need to swap out the actual pattern for whatever makes sense, and ideally you'd pull that programmatically from your python output. But the above would basically replace all of the lines up to 116 (minus the creation of your functions).

Really nice use of sprintf. This is really nice concise syntax. This is all (lines 150-166) rather tricky and I think the code you've come up with is really nice.

Rather than

simi_rtv_non_within_pair %>%
  mutate_at(vars(starts_with("i")), as.integer)

You can just add the additional argument convert = TRUE to separate. For example

separate(col = pair_match, into = c("i1_item", "i2_item"), 
         sep = 2,
         convert = TRUE) %>% 
separate(col = pair_match_obj, into = c("i1_obj", "i2_obj"), 
         sep = 2,
         convert = TRUE)

This will get you the same result.

Relatively minor but I would avoid rbind, which was originally intended for matrices, and instead use dplyr::bind_rows. The latter has the additional benefit of an optional .id argument which regularly comes in handy (it's actually what's used under the hood for map_df).
Although lines 188 to 228 appears to work, this is really counter to the spirit of functional programming. There's a lot of copy/paste work going on here, with just minor edits being made. I've removed a few points here. If there are rules that could be applied a function could have been written to handle the recoding. If there are no rules (which from your comment it sounds like there are not) and everything is truly unique, then I would suggest hand entering this data into a spreadsheet, reading the spreadsheet in as a new data object, and merging it with the existing data object. The data in the spreadsheet would look something like

i1_item	i2_item	simi_cond
1	1	within_item
1	2	same_color
1	3	within_pair
2	2	within_item
2	4	within_pair
..	..	..
20	22	between_pair

Then when you joined the data, you would get the new simi_cond variable, as defined by their match with i1_item and i2_item. Entering data in a spreadsheet like this is less error prone, and merging two datasets is generally a great method for recoding data. Given your comment, it appears you were a bit concerned about this part. Had you of asked me about it prior to turning in your final project I likely would have directed you to this method and you would not have lost any points (although I only removed three points so it's not that big of a deal).

Minor style note, but I think it's best to try to keep everything within a given style, unless there are clear reasons to deviate. I would have rewritten lines 238 to 245 as

dat_rtv <- simi_rtv %>%
  group_by(group, subj_id, atlas_id, roi_id, roi_hemi, simi_cond) %>%
  summarise(similarity = mean(similarity)) %>%
  ungroup() %>% 
  filter(!simi_cond == 'other') %>% 
  filter(roi_id %in% c("ANG", "IPS","SPL","HPC","OTC")) %>%
  mutate(group = fct_recode(factor(group), "Paired" = "1", "Control" = "2"),
         simi_cond = factor(simi_cond, 
                            levels = c("within_item", 
                                       "same_color", 
                                       "between_pair", 
                                       "within_pair")))

Also, as a general rule, I'd try to keep your code within 80 characters as a maximum width. You can setup rulers in RStudio to help you with this. That will also ensure if you need to render to PDF that it will all be there and not run off the page (this is violated on line 245).

For your table, I would really encourage you to use meaningful column names rather than variable names. I almost considered removing a couple points for this as an error in the chosen output format but ultimately decided that was too picky. But if the goal is to communicate the findings, it's really important that you provide labels people can understand, not just those familiar with your specific dataset.
Lines 266-284 look great butI'd encourage you to try to use more meaningful object names and variable names, rather than tmp and a. These are okay as placeholders but you really should change them once your code has settled and you want to move forward with it. Otherwise, if you come back to this code 6 months later, it will be much more difficult to decipher what you were trying to do without going through every line.
Plot looks great. Well done.

Irisfee / r3final

Grade and feedback #5

Grading

Feedback